Clean up Gui tests architecture #459

Part of #459.
Proposed merge commit message:
GuiRobot contains an unused method. GuiHandle also has unused
constructor parameters. Tests also tend to use sleep() to allow the
human to observe the effect of the test, but such delays happen
unnecessarily even in headless mode.

Let's
- Clean up GuiRobot.
- Clean up GuiHandle.
- Implement waiting delay for humans and for application events.

v1
@yamgent submitted v1 for review.

[v1 1/9] GuiRobot: Remove push(KeyCodeCombination)
[v1 2/9] GuiRobot: Add pauseForHuman(int)
[v1 3/9] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v1 4/9] GuiHandle: Remove guiRobot from constructor parameters
[v1 5/9] GuiHandle: Remove primaryStage constructor parameter
[v1 6/9] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v1 7/9] HelpWindowTest: Remove return type HelpWindowHandle
[v1 8/9] ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"
[v1 9/9] MainMenuHandle: Inline useF1Accelerator()

(:books: Archive)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/1/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

v2
@yamgent submitted v2 for review.

[v2 1/9] GuiRobot: Remove push(KeyCodeCombination)
[v2 2/9] GuiRobot: Add pauseForHuman(int)
[v2 3/9] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v2 4/9] GuiHandle: Remove guiRobot from constructor parameters
[v2 5/9] GuiHandle: Remove primaryStage constructor parameter
[v2 6/9] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v2 7/9] HelpWindowTest: Remove return type HelpWindowHandle
[v2 8/9] ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"
[v2 9/9] MainMenuHandle: Inline useF1Accelerator()

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v1 and v2)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/2/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@yamgent This PR really ready for review or not :-S

v3
@yamgent submitted v3 for review.

[v3 1/40] GuiRobot: Remove push(KeyCodeCombination)
[v3 2/40] GuiRobot: Add pauseForHuman(int)
[v3 3/40] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v3 4/40] GuiHandle: Remove guiRobot from constructor parameters
[v3 5/40] GuiHandle: Remove primaryStage constructor parameter
[v3 6/40] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v3 7/40] HelpWindowTest: Remove return type HelpWindowHandle
[v3 8/40] ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"
[v3 9/40] MainMenuHandle: Inline useF1Accelerator()
[v3 10/40] Change GuiRobot to be a singleton
[v3 11/40] PersonCardHandle: Encapsulate labels and region
[v3 12/40] Clean up PersonCardHandle
[v3 13/40] PersonListPanelHandle: Change getSelectedPerson()
[v3 14/40] PersonListPanelHandle: Extract cardAndPersonMatch(...)
[v3 15/40] Tidy up PersonListPanelHandle#isListMatching(...)
[v3 16/40] Remove PersonListPanelHandle#containsInOrder(...)
[v3 17/40] PersonListPanelHandle#navigateToPerson(...): Use Person instead of index
[v3 18/40] PersonListPanelHandle: Remove unused methods
[v3 19/40] AlertDialogHandle#isMatching(String, String): Remove redundant variable
[v3 20/40] StatusBarFooterHandle: Remove unused getSaveLocation() method
[v3 21/40] GuiHandle: Move pressEnter() to GuiRobot
[v3 22/40] GuiHandle: Move setTextFieldText() to GuiRobot#enterText()
[v3 23/40] ErrorDialogGuiTest: Extract string constants
[v3 24/40] MainGuiHandle: Encapsulate handles
[v3 25/40] MainGuiHandle: Remove getAlertDialog(String)
[v3 26/40] AddressBookGuiTest: Remove component handles.
[v3 27/40] AddressBookGuiTest#setup(): Remove redundant wait for stage to show
[v3 28/40] AddressBookGuiTest#setup(): Remove redundant EventsCenter reset
[v3 29/40] CommandBoxHandle: Inline enterCommand()
[v3 30/40] CommandBoxHandle: Rename runCommand(String) to enterCommand(String)
[v3 31/40] CommandBoxHandle: Remove runHelpCommand()
[v3 32/40] AddressBookGuiTest: Add guiRobot
[v3 33/40] AlertDialogHandle: Tidy up isMatching()
[v3 34/40] HelpWindowHandle#closeWindow(): Check that window is closed
[v3 35/40] PersonListPanelHandle#navigateToPerson(...): Throw PersonNotFoundException
[v3 36/40] Tidy up header comments for *Handle classes
[v3 37/40] PersonListPanelHandle#navigateToPerson(...): Make it private
[v3 38/40] Tidy up AddressBookGuiTest
[v3 39/40] MainMenuHandle: Inline openHelpWindowUsingAccelerator()
[v3 40/40] Tidy up MainMenuHandle

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v2 and v3)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/3/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@thenaesh review

@thenaesh

But the level of code quality is just amazing!  Use Person instead of index
[v4 18/42] PersonListPanelHandle: Remove unused getPersonIndex(int)
[v4 19/42] AlertDialogHandle#isMatching(String, String): Remove redundant variable
[v4 20/42] StatusBarFooterHandle: Remove unused getSaveLocation() method
[v4 21/42] GuiHandle: Move pressEnter() to GuiRobot
[v4 22/42] GuiHandle: Move setTextFieldText() to GuiRobot#enterText()
[v4 23/42] ErrorDialogGuiTest: Extract string constants
[v4 24/42] MainGuiHandle: Encapsulate handles
[v4 25/42] MainGuiHandle: Remove getAlertDialog(String)
[v4 26/42] AddressBookGuiTest: Remove component handles.
[v4 27/42] AddressBookGuiTest#setup(): Remove redundant wait for stage to show
[v4 28/42] AddressBookGuiTest#setup(): Remove redundant EventsCenter reset
[v4 29/42] CommandBoxHandle: Inline enterCommand()
[v4 30/42] CommandBoxHandle: Rename runCommand(String) to enterCommand(String)
[v4 31/42] CommandBoxHandle: Remove runHelpCommand()
[v4 32/42] AddressBookGuiTest: Add guiRobot
[v4 33/42] AlertDialogHandle: Tidy up isMatching()
[v4 34/42] HelpWindowHandle#closeWindow(): Check that window is closed
[v4 35/42] PersonListPanelHandle#navigateToPerson(): Throw PersonNotFoundException
[v4 36/42] Tidy up header comments for *Handle classes
[v4 37/42] PersonListPanelHandle: Make navigateToPerson(...) private
[v4 38/42] Tidy up AddressBookGuiTest
[v4 39/42] MainMenuHandle: Inline openHelpWindowUsingAccelerator()
[v4 40/42] HelpWindowTest: Remove unnecessary pauseForHuman() after pushing F1
[v4 41/42] Tidy up MainMenuHandle
[v4 42/42] Tidy up ErrorDialogGuiTest

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v3 and v4)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/4/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@limmlingg For your approval please.

@damithc @pyokagan PR ready for review.
This is part 1, just cleaning up the GUI test architecture overall. Part 2 (adding NodeHandle and WindowHandle), will be in a separate branch and a separate PR (https://github.com/yamgent/addressbook-level4/commits/459-node-window-handle)

@yamgent Submit a new version.

v5
@yamgent submitted v5 for review.

[v5 1/47] GuiRobot: Remove push(KeyCodeCombination)
[v5 2/47] GuiRobot: Add pauseForHuman(int)
[v5 3/47] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v5 4/47] GuiHandle: Remove guiRobot from constructor parameters
[v5 5/47] GuiHandle: Remove primaryStage constructor parameter
[v5 6/47] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v5 7/47] HelpWindowTest: Remove return type HelpWindowHandle
[v5 8/47] ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"
[v5 9/47] MainMenuHandle: Inline useF1Accelerator()
[v5 10/47] Change GuiRobot to be a singleton
[v5 11/47] PersonCardHandle: Encapsulate labels and region
[v5 12/47] Clean up PersonCardHandle
[v5 13/47] PersonListPanelHandle: Change getSelectedPerson()
[v5 14/47] PersonListPanelHandle: Extract cardAndPersonMatch(...)
[v5 15/47] Tidy up PersonListPanelHandle#isListMatching(...)
[v5 16/47] Remove PersonListPanelHandle#containsInOrder(...)
[v5 17/47] PersonListPanelHandle#navigateToPerson(...): Use Person instead of index
[v5 18/47] PersonListPanelHandle: Remove unused getPersonIndex(int)
[v5 19/47] AlertDialogHandle#isMatching(String, String): Remove redundant variable
[v5 20/47] StatusBarFooterHandle: Remove unused getSaveLocation() method
[v5 21/47] GuiHandle: Move pressEnter() to GuiRobot
[v5 22/47] GuiHandle: Move setTextFieldText() to GuiRobot#enterText()
[v5 23/47] ErrorDialogGuiTest: Extract string constants
[v5 24/47] MainGuiHandle: Encapsulate handles
[v5 25/47] MainGuiHandle: Remove getAlertDialog(String)
[v5 26/47] AddressBookGuiTest: Remove component handles.
[v5 27/47] AddressBookGuiTest#setup(): Remove redundant wait for stage to show
[v5 28/47] AddressBookGuiTest#setup(): Remove redundant EventsCenter reset
[v5 29/47] CommandBoxHandle: Inline enterCommand()
[v5 30/47] CommandBoxHandle: Rename runCommand(String) to enterCommand(String)
[v5 31/47] CommandBoxHandle: Remove runHelpCommand()
[v5 32/47] AddressBookGuiTest: Add guiRobot
[v5 33/47] AlertDialogHandle: Tidy up isMatching()
[v5 34/47] HelpWindowHandle#closeWindow(): Check that window is closed
[v5 35/47] PersonListPanelHandle#navigateToPerson(): Throw PersonNotFoundException
[v5 36/47] Tidy up header comments for *Handle classes
[v5 37/47] PersonListPanelHandle: Make navigateToPerson(...) private
[v5 38/47] Tidy up AddressBookGuiTest
[v5 39/47] MainMenuHandle: Inline openHelpWindowUsingAccelerator()
[v5 40/47] HelpWindowTest: Remove unnecessary pauseForHuman() after pushing F1
[v5 41/47] Tidy up MainMenuHandle
[v5 42/47] Tidy up ErrorDialogGuiTest
[v5 43/47] PersonListPanelHandle#navigateToPerson(): Remove pauseForHuman() calls
[v5 44/47] CommandBoxHandle#enterCommand(): Remove pause after pressing Enter
[v5 45/47] StatusBarFooterTest: Add pauses for tests
[v5 46/47] HelpWindowHandle: Move calls for pauseInHuman(int) to HelpWindowTest
[v5 47/47] GuiRobot#waitForEvent(): Add timed pause

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v4 and v5)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/5/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

v6
@yamgent submitted v6 for review.

[v6 1/47] GuiRobot: Remove push(KeyCodeCombination)
[v6 2/47] GuiRobot: Add pauseForHuman(int)
[v6 3/47] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v6 4/47] GuiHandle: Remove guiRobot from constructor parameters
[v6 5/47] GuiHandle: Remove primaryStage constructor parameter
[v6 6/47] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v6 7/47] HelpWindowTest: Remove return type HelpWindowHandle
[v6 8/47] ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"
[v6 9/47] MainMenuHandle: Inline useF1Accelerator()
[v6 10/47] Change GuiRobot to be a singleton
[v6 11/47] PersonCardHandle: Encapsulate labels and region
[v6 12/47] Clean up PersonCardHandle
[v6 13/47] PersonListPanelHandle: Change getSelectedPerson()
[v6 14/47] PersonListPanelHandle: Extract cardAndPersonMatch(...)
[v6 15/47] Tidy up PersonListPanelHandle#isListMatching(...)
[v6 16/47] Remove PersonListPanelHandle#containsInOrder(...)
[v6 17/47] PersonListPanelHandle#navigateToPerson(...): Use Person instead of index
[v6 18/47] PersonListPanelHandle: Remove unused getPersonIndex(int)
[v6 19/47] AlertDialogHandle#isMatching(String, String): Remove redundant variable
[v6 20/47] StatusBarFooterHandle: Remove unused getSaveLocation() method
[v6 21/47] GuiHandle: Move pressEnter() to GuiRobot
[v6 22/47] GuiHandle: Move setTextFieldText() to GuiRobot#enterText()
[v6 23/47] ErrorDialogGuiTest: Extract string constants
[v6 24/47] MainGuiHandle: Encapsulate handles
[v6 25/47] MainGuiHandle: Remove getAlertDialog(String)
[v6 26/47] AddressBookGuiTest: Remove component handles.
[v6 27/47] AddressBookGuiTest#setup(): Remove redundant wait for stage to show
[v6 28/47] AddressBookGuiTest#setup(): Remove redundant EventsCenter reset
[v6 29/47] CommandBoxHandle: Inline enterCommand()
[v6 30/47] CommandBoxHandle: Rename runCommand(String) to enterCommand(String)
[v6 31/47] CommandBoxHandle: Remove runHelpCommand()
[v6 32/47] AddressBookGuiTest: Add guiRobot
[v6 33/47] AlertDialogHandle: Tidy up isMatching()
[v6 34/47] HelpWindowHandle#closeWindow(): Check that window is closed
[v6 35/47] PersonListPanelHandle#navigateToPerson(): Throw PersonNotFoundException
[v6 36/47] Tidy up header comments for *Handle classes
[v6 37/47] PersonListPanelHandle: Make navigateToPerson(...) private
[v6 38/47] Tidy up AddressBookGuiTest
[v6 39/47] MainMenuHandle: Inline openHelpWindowUsingAccelerator()
[v6 40/47] HelpWindowTest: Remove unnecessary pauseForHuman() after pushing F1
[v6 41/47] Tidy up MainMenuHandle
[v6 42/47] Tidy up ErrorDialogGuiTest
[v6 43/47] PersonListPanelHandle#navigateToPerson(): Remove pauseForHuman() calls
[v6 44/47] CommandBoxHandle#enterCommand(): Remove pause after pressing Enter
[v6 45/47] StatusBarFooterTest: Add pauses for tests
[v6 46/47] HelpWindowHandle: Move calls for pauseInHuman(int) to HelpWindowTest
[v6 47/47] GuiRobot#waitForEvent(): Add timed pause

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v5 and v6)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/6/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@pyokagan Hold on, I missed some of @Zhiyuan-Amos's comments, sorry about that.

v7
@yamgent submitted v7 for review.

[v7 1/48] GuiRobot: Remove push(KeyCodeCombination)
[v7 2/48] GuiRobot: Add pauseForHuman(int)
[v7 3/48] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v7 4/48] GuiHandle: Remove guiRobot from constructor parameters
[v7 5/48] GuiHandle: Remove primaryStage constructor parameter
[v7 6/48] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v7 7/48] HelpWindowTest: Remove return type HelpWindowHandle
[v7 8/48] ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"
[v7 9/48] MainMenuHandle: Inline useF1Accelerator()
[v7 10/48] Change GuiRobot to be a singleton
[v7 11/48] PersonCardHandle: Encapsulate labels and region
[v7 12/48] Clean up PersonCardHandle
[v7 13/48] PersonListPanelHandle: Change getSelectedPerson()
[v7 14/48] PersonListPanelHandle: Extract cardAndPersonMatch(...)
[v7 15/48] Tidy up PersonListPanelHandle#isListMatching(...)
[v7 16/48] Remove PersonListPanelHandle#containsInOrder(...)
[v7 17/48] PersonListPanelHandle#navigateToPerson(...): Use Person instead of index
[v7 18/48] PersonListPanelHandle: Remove unused getPersonIndex(int)
[v7 19/48] AlertDialogHandle#isMatching(String, String): Remove redundant variable
[v7 20/48] StatusBarFooterHandle: Remove unused getSaveLocation() method
[v7 21/48] GuiHandle: Move pressEnter() to GuiRobot
[v7 22/48] GuiHandle: Move setTextFieldText() to GuiRobot#enterText()
[v7 23/48] ErrorDialogGuiTest: Extract string constants
[v7 24/48] MainGuiHandle: Encapsulate handles
[v7 25/48] MainGuiHandle: Remove getAlertDialog(String)
[v7 26/48] AddressBookGuiTest: Remove component handles.
[v7 27/48] AddressBookGuiTest#setup(): Remove redundant wait for stage to show
[v7 28/48] AddressBookGuiTest#setup(): Remove redundant EventsCenter reset
[v7 29/48] CommandBoxHandle: Inline enterCommand()
[v7 30/48] CommandBoxHandle: Rename runCommand(String) to submitCommand(String)
[v7 31/48] CommandBoxHandle: Remove runHelpCommand()
[v7 32/48] AddressBookGuiTest: Add guiRobot
[v7 33/48] AlertDialogHandle: Tidy up isMatching()
[v7 34/48] HelpWindowHandle#closeWindow(): Check that window is closed
[v7 35/48] PersonListPanelHandle#navigateToPerson(): Throw PersonNotFoundException
[v7 36/48] Tidy up header comments for *Handle classes
[v7 37/48] PersonListPanelHandle: Make navigateToPerson(...) private
[v7 38/48] Tidy up AddressBookGuiTest
[v7 39/48] MainMenuHandle: Inline openHelpWindowUsingAccelerator()
[v7 40/48] HelpWindowTest: Remove unnecessary pauseForHuman() after pushing F1
[v7 41/48] Tidy up MainMenuHandle
[v7 42/48] Tidy up ErrorDialogGuiTest
[v7 43/48] PersonListPanelHandle#navigateToPerson(): Remove pauseForHuman() calls
[v7 44/48] CommandBoxHandle#enterCommand(): Remove pause after pressing Enter
[v7 45/48] StatusBarFooterTest: Add pauses for tests
[v7 46/48] HelpWindowHandle: Move calls for pauseInHuman(int) to HelpWindowTest
[v7 47/48] GuiRobot#waitForEvent(): Add timed pause
[v7 48/48] GuiRobot: Inline enterText() and pressEnter()

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v6 and v7)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/7/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@pyokagan Ready for review.

@yamgent I'll stop here. Remember to give a changelog for every new iteration submitted.

@pyokagan Thanks for the reviews so far! Will correct the first 10 commits and submit the next iteration soon.

v8
@yamgent submitted v8 for review.

[v8 1/48] GuiRobot: Remove push(KeyCodeCombination)
[v8 2/48] TestUtil: Remove scrub(KeyCodeCombination)
[v8 3/48] GuiRobot: Add pauseForHuman(int)
[v8 4/48] ErrorDialogGuiTest: Implement smart wait for showErrorDialogs()
[v8 5/48] GuiHandle: Remove guiRobot from constructor parameters
[v8 6/48] GuiHandle: Remove primaryStage constructor parameter
[v8 7/48] GuiRobot#pauseForHuman(int): Use constants instead of magic numbers
[v8 8/48] HelpWindowTest: Remove return type HelpWindowHandle
[v8 9/48] MainMenuHandle: Inline useF1Accelerator()
[v8 10/48] Change GuiRobot to be a singleton
[v8 11/48] PersonCardHandle: Encapsulate labels and region
[v8 12/48] Clean up PersonCardHandle
[v8 13/48] PersonListPanelHandle: Change getSelectedPerson()
[v8 14/48] PersonListPanelHandle: Extract cardAndPersonMatch(...)
[v8 15/48] Tidy up PersonListPanelHandle#isListMatching(...)
[v8 16/48] Remove PersonListPanelHandle#containsInOrder(...)
[v8 17/48] PersonListPanelHandle#navigateToPerson(...): Use Person instead of index
[v8 18/48] PersonListPanelHandle: Remove unused getPersonIndex(int)
[v8 19/48] AlertDialogHandle#isMatching(String, String): Remove redundant variable
[v8 20/48] StatusBarFooterHandle: Remove unused getSaveLocation() method
[v8 21/48] GuiHandle: Move pressEnter() to GuiRobot
[v8 22/48] GuiHandle: Move setTextFieldText() to GuiRobot#enterText()
[v8 23/48] ErrorDialogGuiTest: Extract string constants
[v8 24/48] MainGuiHandle: Encapsulate handles
[v8 25/48] MainGuiHandle: Remove getAlertDialog(String)
[v8 26/48] AddressBookGuiTest: Remove component handles.
[v8 27/48] AddressBookGuiTest#setup(): Remove redundant wait for stage to show
[v8 28/48] AddressBookGuiTest#setup(): Remove redundant EventsCenter reset
[v8 29/48] CommandBoxHandle: Inline enterCommand()
[v8 30/48] CommandBoxHandle: Rename runCommand(String) to submitCommand(String)
[v8 31/48] CommandBoxHandle: Remove runHelpCommand()
[v8 32/48] AddressBookGuiTest: Add guiRobot
[v8 33/48] AlertDialogHandle: Tidy up isMatching()
[v8 34/48] HelpWindowHandle#closeWindow(): Check that window is closed
[v8 35/48] PersonListPanelHandle#navigateToPerson(): Throw PersonNotFoundException
[v8 36/48] Tidy up header comments for *Handle classes
[v8 37/48] PersonListPanelHandle: Make navigateToPerson(...) private
[v8 38/48] Tidy up AddressBookGuiTest
[v8 39/48] MainMenuHandle: Inline openHelpWindowUsingAccelerator()
[v8 40/48] HelpWindowTest: Remove unnecessary pauseForHuman() after pushing F1
[v8 41/48] Tidy up MainMenuHandle
[v8 42/48] Tidy up ErrorDialogGuiTest
[v8 43/48] PersonListPanelHandle#navigateToPerson(): Remove pauseForHuman() calls
[v8 44/48] CommandBoxHandle#enterCommand(): Remove pause after pressing Enter
[v8 45/48] StatusBarFooterTest: Add pauses for tests
[v8 46/48] HelpWindowHandle: Move calls for pauseInHuman(int) to HelpWindowTest
[v8 47/48] GuiRobot#waitForEvent(): Add timed pause
[v8 48/48] GuiRobot: Inline enterText() and pressEnter()

(:books: Archive) (:chart_with_upwards_trend: Interdiff between v7 and v8)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/489/8/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

v8
Changes requested by Paul made.

'[v8 2/48] TestUtil: Remove scrub(KeyCodeCombination)' is a new commit that was split from [v8 1/48]
[v8 7/48]: Explanations made on why we use multiple values for pauseForHuman(int).
Dropped [v7 8/48]: ErrorDialogGuiTest#showErrorDialogs(): Remove "Stub"

With one commit added and one commit dropped, the number of commits remained the same, so you can resume from [v8 11/48].

I'm stopping here. It is starting to seem that this PR contains too many unrelated cleanups.
@yamgent Is there a way to have only the essential commits needed to rework the GuiHandles and GuiRobot?

I think commits 1 to 4 and 7 can be moved into their own PR on the topic of removing guiRobot.sleep() usages.

Ok, will look at moving the commits around and splitting into different PRs where possible.

As this PR will be split up, and a lot of these commits are interdependent on each other, this PR will be on hold.

More than 1 month ago bro ;P

Commit [StatusBarFooterTest: Add pauses for tests] may no longer be necessary, because:

Its GUI unit test equivalent StatusBarFooterTest#assertStatusBarContent() already calls guiRobot#pauseForHuman().
guitests\StatusBarFooterTest.java will eventually be replaced by a system test, and will be removed.

This PR is superseded by #508, #503, #511, #512, #515, #514, #520, #531, #522, #572, #573.


Proposal: Make API for /containers/(id)/top independent of implementation

Background and Problem
Issue #7205 and discussion therein, describes some problems with the current API with regard to the:
GET /containers/(id)/top

API endpoint. I think these problems can be boiled down to a single issue which is that
the API includes ps_args which are not bounded and are not in control of the API itself.
The result is different output on different systems even when using the same arguments.
The existing implementation uses ps to gather the data but the API does not allow
alternate implementations because it is not fully defined.
This proposal also makes it possible to normalize the behavior across existing hosts,
as different docker hosts with slightly different versions of ps already exhibit minor
differences in response (see for example #8075).
As docker is ported to other platforms which may or may not have the same behavior and
may in fact not even have a ps command host-side, I think this will become more of an
issue. I'm making this proposal in attempt to make something which can be supported by
other platforms and also be implemented differently on Linux hosts in the future (Eg.
the /proc reader that was suggested in #7205).
Existing Behavior
On an Ubuntu 14.04 host with docker 1.3.1 the default fields I get when I use
docker top <id> with no ps_args are:

UID
PID
PPID
C
STIME
TTY
TIME
CMD

Which is the equivalent to running ps -ef on the host.
The API docs for v1.15 also refer to aux as an example for ps_args. With that
the fields are:

USER
PID
%CPU
%MEM
VSZ
RSS
TTY
STAT
START
TIME
COMMAND

which actually has very little overlap with the default set.
What I'd like to propose is that the ps_args parameter go away, to be replaced
by a fields parameter which defines the ordered set of fields that should be in
the output. The possible fields should be clearly defined and a finite set. I've
attempted to err here on the side of including fewer fields as it's much easier
to add them later than to include them now and take them away later.
I've also attempted to move away from implementation-specific formatting for
things like 'start_time' and 'cputime' which on Linux are formatted as "MmmDD"
or "HH:MM" for 'start_time' (depending how old) and '[DD-]hh:mm:ss' for
'cputime'. These are both confusing formats and also lose information that
implementations may otherwise have. For example, on the same Linux system
/proc//sched contains this information with microsecond precision.
Proposal
I propose that initially the set of allowed 'fields' would include:

field
type
description

c
integer
processor utilization over process lifetime

comm
string
command name (only the executable name)

command
string
command with all its arguments

cputime
number
cumulative CPU time for the process in seconds, with or without decimals

gid
integer
effective group ID number of the process as a decimal integer

lwp
integer
light weight process (thread) ID of the dispatchable entity

nice
integer
nice value. This ranges from 19 (nicest) to -20 (not nice to others)

pcpu
number
cpu utilization of the process as a percentage of its run time, with or without decimals

pid
integer
a number representing the process ID

pgid
integer
process group ID or, equivalently, the process ID of the process group leader

pmem
integer
ratio of the process's resident set size to the physical memory on the machine, expressed as a percentage

ppid
integer
parent process ID

psr
integer
processor that process is currently assigned to

rgid
integer
real group ID

rss
integer
resident set size, the non-swapped physical memory that a task has used in KiB

ruid
integer
real user ID

start_time
number
time the process started (seconds since 1970-01-01 00:00:00 UTC), with or without decimals

state
string (see 'state fields')
normalized state of the process

state_flags
string (see 'state fields')
implementation-specific process state flags

tty
string
controlling tty (terminal)

uid
integer
effective user ID

vsz
integer
virtual size of the process in KiB

So the default for fields would be:
fields=uid,pid,ppid,c,start_time,tty,cputime,command

which contains all the data the client would require in order to generate the
existing default v1.15 output of 'docker top', whether the client would want to
display it this way or in some more useful fashion.
I'd also define a special option:
fields=all

which would be identical to all the fields:
fields=c,comm,command,cputime,gid,lwp,nice,pcpu,pid,pgid,pmem,ppid,psr,rgid,rss,ruid,start_time,state,state_flags,tty,uid,vsz

NOTE:

The fields list purposefully does not include an analog to the "USER" ps
field, because it doesn't seem likely that most implementations (the current
one doesn't for example) will display the user names here from the guest's
context, and would fallback to UID anyway.

state fields
In order to make the state and state_flags fields more generic and in
attempt to make them more portable these fields should be defined as follows
for state (ps state is included here for reference only):

State
ps state
Meaning

uninterruptible
D
uninterruptible sleep (usually IO)

running
R
running or runnable (on run queue)

sleep
S
interruptible sleep (waiting for an event to complete)

stopped
T
stopped, either by a job control signal or because it is being traced

zombie
Z
defunct ("zombie") process, terminated but not reaped by its parent

And the state_flags should be a comma separated list of strings representing
It is possible that some implementations will not support these flags. As such,
clients should not fail when this list is empty. Supported values at this point
should include (ps stat here represents the Linux character used to indicate
this flag with the stat field, again only for reference):

Flag
ps stat
Meaning

high
<
high-priority (not nice to other users)

low
N
low-priority (nice to other users)

locked
L
has pages locked into memory (for real-time and custom IO)

leader
s
is a session leader

threads
l
is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)

foreground
+
is in the foreground process group

So an example ps aux output that included:
syslog     948  0.0  1.6<PHONE_NUMBER>0 ?        Ssl  Nov06   0:08 rsyslogd
root      1037  0.0  0.0      0     0 ?        S<   Nov06   0:00 [dm_bufio_cache]
root      1114  0.0  0.0  14540   956 tty4     Ss+  Nov06   0:00 /sbin/getty -8 38400 tty4

The state field for all three of these problems would be 'sleep' and the
state_flags fields would be:

leader,threads
high
foreground,leader

respectively.
Backward compatibility (optional)
For the initial version (in order to support existing usage) ps_args could still
be supported but deprecated and defined in the above terms. Eg.
ps_args=aux

would be translated into:
fields=uid,pid,pcpu,pmem,vsz,rss,tty,stat,stime,time,command

however a specific limited set of ps_args values would need to be chosen here.
My own bias would be toward keeping compatibility only for older clients. Ie. have
the code use the old behavior for v1.15 and older clients and the new behavior only
for v1.16 and higher clients.
Responses
Current responses look like (copied from the v1.15 API doc):
    {
         "Titles":[
                 "USER",
                 "PID",
                 "%CPU",
                 "%MEM",
                 "VSZ",
                 "RSS",
                 "TTY",
                 "STAT",
                 "START",
                 "TIME",
                 "COMMAND"
                 ],
         "Processes":[
                 ["root","20147","0.0","0.1","18060","1864","pts/4","S","10:06","0:00","bash"],
                 ["root","20271","0.0","0.0","4312","352","pts/4","S+","10:07","0:00","sleep","10"]
         ]
    }

and I propose to change the output to something like:
    {
         "Processes":[
                 {
                          "uid": 0,
                          "pid": 20147,
                          "pcpu": 0.0,
                          "pmem": 0.1,
                          "vsz": 18060,
                          "rss": 1864,
                          "tty": "pts/4",
                          "state": "stopped",
                          "state_flags": "",
                          "start_time":<PHONE_NUMBER>,
                          "time": 0.0001,
                          "command": "bash"
                 }, {
                          "uid": 0,
                          "pid": 20271,
                          "pcpu": 0.0,
                          "pmem": 0.0,
                          "vsz": 4312,
                          "rss": 352,
                          "tty": "pts/4",
                          "state": "stopped",
                          "state_flags": "foreground",
                          "start_time":<PHONE_NUMBER>,
                          "time": 0.0002,
                          "command": "sleep 10"
                 }
         ]
    }

which makes it easier for the client to know the which field is which in the
response. Combined with 'fields=all' this also allows a client to determine
which fields a given implementation/server-version supports.
I would also suggest the addition of an additional status code:

422 – invalid fields

for the case where invalid values are requested for fields.
CLI changes
In order to support this new API, I propose the CLI interface to this endpoint be
modified from:
docker ps [ps ARGS]

to:
docker ps [FIELDS]

with the fields matching those defined by the API. The output here would be the requested
fields in the order they were requested. Eg:
$ sudo docker top 8601afda2b pid tty state state_flags cpu_time command
pid      tty       state    state_flags   cpu_time    command
16623    ?         S        leader        0.03        sleep 99999

Implementation notes
The initial implementation here in docker would be straight-forward since all these
fields map to ps fields and the initial implementation could be splitting apart the
fields from:
ps -Ho <fields>

With some translation on the server side. Specifically:

cputime would need to be turned into a number from the 'HH:MM:SS' default format of 'cputime'
start_time would need to be turned into a number from the default format of 'start_time'
state would need to be a simple table-translation of single-character state -> string
state_flags would be a simple table-translation of all the special 'stat' characters -> array of strings

Other implementations however would now be much simpler as we could for
example read data out of /proc and generate objects with the specified fields
without a problem.

I am +1 for the rationale. I completely agree that the current situation is not acceptable: if we embed it in our API, the API docs should specify it and we should be able to take responsibility for the output.
A few comments:

The "long command" field is a string, but I believe the command can be retrieved with proper word separation (ie /proc//cmdline). Could we preserve that information and pass a []string{} instead?
I don't like comm and command as field names, they are not memorable. How about cmd and cmdline.
Please make a best effort for reverse compatibility, but realistically it won't be 100% in this case since the current behavior is partially undefined anyway.
As long as the above comments are respected, I would like to hand off design ownership to someone else. Any volunteers @bfirsh @crosbymichael @aanand?

@shykes FWIW, the comm and command field names are taken from man ps' table of "STANDARD FORMAT SPECIFIERS".
Here are the relevant parts from http://www.freebsd.org/cgi/man.cgi?query=ps&manpath=CentOS+7.0
...
       args	   COMMAND   command with all its arguments as a string.
			     Modifications to the arguments may	be shown.  The
			     output in this column may contain spaces.	A
			     process marked <defunct> is partly	dead, waiting
			     to	be fully destroyed by its parent.  Sometimes
			     the process args will be unavailable; when	this
			     happens, ps will instead print the	executable
			     name in brackets.	(alias cmd, command).  See
			     also the comm format keyword, the -f option, and
			     the c option.
			     When specified last, this column will extend to
			     the edge of the display.  If ps can not determine
			     display width, as when output is redirected
			     (piped) into a file or another command, the
			     output width is undefined (it may be 80,
			     unlimited,	determined by the TERM variable, and
			     so	on).  The COLUMNS environment variable or
			     --cols option may be used to exactly determine
			     the width in this case.  The w or -w option may
			     be	also be	used to	adjust width.
...
       cmd	   CMD	     see args.	(alias args, command).

       comm	   COMMAND   command name (only	the executable name).
			     Modifications to the command name will not	be
			     shown.  A process marked <defunct>	is partly
			     dead, waiting to be fully destroyed by its
			     parent.  The output in this column	may contain
			     spaces.  (alias ucmd, ucomm).  See	also the args
			     format keyword, the -f option, and	the c option.
			     When specified last, this column will extend to
			     the edge of the display.  If ps can not determine
			     display width, as when output is redirected
			     (piped) into a file or another command, the
			     output width is undefined (it may be 80,
			     unlimited,	determined by the TERM variable, and
			     so	on).  The COLUMNS environment variable or
			     --cols option may be used to exactly determine
			     the width in this case.  The w or -w option may
			     be	also be	used to	adjust width.

       command	   COMMAND   See args.	(alias args, command).
...

Perhaps using args (command with all args) and comm (just the executable name) would satisfy being memorable and maintain semantics with the ps specifiers with the same name?

Should someone in the Microsoft camp have a look at this as well, to check if all these can be offered in future Windows implementations of the daemon, or is that of no concern for now?

I'm tentatively scheduling this for 1.6 since there is broad consensus on the need for having a better definition of the top API. We'll need to agree on a few details from the last comments.
We could definitely get some input from Microsoft on this to know if they have any concerns on the proposed API. /cc @ahmetalpbalkan @johngossman

the cli.md doc also needs an update (and the API change to move to the not yet created API doc.)

Thanks @joshwilsdon! I'm closing this PR but we can consider the design to be agreed on (thanks to @shykes and @tiborvass).
Feel free to submit a new PR with an implementation when you have one ready, and reference this one to make sure that design review doesn't happen all over again :-)

@ahmetalpbalkan what do you think of this?

@tiborvass you should probably check with windows server folks as I am not the authority on subject and I don't know what's their plan for this endpoint.

@jhowardmsft what do you think of this?

Initial thoughts (top isn't something yet implemented in the Windows daemon or a code path I've looked at yet..) - clearly the fields will be different between Linux and Windows. I'm talking to some of the container folks to determine if there's a clear mapping here, but looking at the list, I believe it's going to be fairly evident this isn't the case without fitting a square peg in a round hole.
I like the idea of being able to specify the list of fields. I think that as long as the "default" list is defined server side, not in the client, and the list of all possible fields similarly defined and validated in the daemon code so that we can have Linux and Windows versions of the "default" fields and all possible fields, we're good. That way at least, we wouldn't have to update the client should the list be changed in the future.


Support for Hints

Does this library include support for the Hints feature of IntroJS?

@adambedford Yes, please take a look at the readme:
https://github.com/PoslinskiNet/ember-introjs#2-use-intro-jsstep-component-as-a-wrapper
hint keys

@PoslinskiNet I think we have only implemented basic hints usage. Not the whole API :/

As far as I see, we have both attributes currently available in the IntroJS already implemented in the wrapper:
http://introjs.com/docs/hints/attributes/

Yes we have just the attributes nor the options and api

Ok, hints options are not there yet ... so it is on TODO list then :)


Parallel iterators should just fail early in case of panic instead of continuing to issue more workers

When using a parallel iterator if a panic happens in one of the threads that doesn't stop more threads from being launched. This is a surprising behavior since in the equivalent sequential code the loop will terminate early because of the panic. This can lead to DoS in code like this:
extern crate rayon;
use self::rayon::prelude::*;

fn main() {
    let width  = 10;
    let height = 10;

    let mut out: Vec<u16> = vec![0u16; width*height];
    out.par_chunks_mut(width).enumerate().for_each(|(row, _line)| {
        panic!("panic at row {}", row);
    });
}

When height is very large it takes forever to issue panics for all the lines. I hit this when fuzzing a binary image format where a well crafted file would take advantage of this to force the code to go through the slow panic processing path a few million times and cause a DoS. The bug is introduced by the parallel iterator as the sequential code would bail at the first panic.

This on the other hand works as expected:
extern crate rayon;
use self::rayon::prelude::*;
use std::panic;

fn main() {
    let width  = 10;
    let height = 10;

    let mut out: Vec<u16> = vec![0u16; width*height];
    out.par_chunks_mut(width).enumerate().try_for_each(|(row, _line)| {
        panic::catch_unwind(|| panic!("panic at row {}", row))
    }).ok();
}

So the mechanism to abort early already exists for the try_for_each variant, it's just not used for panics in for_each.

At the low level in rayon-core, where panics are caught and propagated, it doesn't know about parallel iterators or what jobs are related. It can only see a connection in that iterators use join, but we have explicitly documented its panic behavior like so:

No matter what happens, both closures will always be executed. If a single closure panics, whether it be the first or second closure, that panic will be propagated and hence join() will panic with the same panic value. If both closures panic, join() will panic with the panic value from the first closure.

The implementation of try_for_each maintains a shared AtomicBool across all threads to track its completion state. I think that's too much synchronization to force on for_each and all other parallel iterators.
IMO, panics should be seen as an exceptional case, where we strive for safety and correctness, but don't necessarily worry about performance. If you're worried about DoS, I can imagine plenty of scenarios where bad input causes extraordinary processing time without any panic. Still, your custom solution with panic::catch_unwind seems appropriate if you want to be more defensive.

I wonder if we might add a kind of wrapper, sort of like fuse, that adds the panic propagation.

It seems plausible to do.

The behavior of join makes sense, I hadn't inferred from that the behavior of the iterator though. I had assumed that once enough panics had propagated (maybe one per thread in the pool at least) the iterator would abort. But that was with a mental model of a serial loop launching threads as they become available in the pool. I guess an iterator is instead conceptually join(A, join(B, join (C...))) and thus there's no point where a join has already returned with panic and further threads can stop being launched. Is there any downside to just aborting the second side of the join if the first side has already panic'ed and the second side is still waiting for a thread? Surely if you're already in a panic situation you're not depending on results from the second operation?
The try_for_each version works for the minimized test case but not for the actual code because the catch_unwind boundary limits what can be passed in to a closure. I've fixed the DoS by just limiting height to a reasonable value so at most this is now a small slowdown instead of an actual DoS. But since the behavior was surprising to me I thought I should report it.
It would still be nice to fix this somehow. If nothing else it makes debugging harder because you get a long list of repeat panics instead of just a few at most  If there's a simple way to add that check I'd be happy to benchmark it thoroughly in rawloader. It runs a bunch of threaded tight loops for all its decoders, so performance regressions here would be bad, and I already have everything setup to do meaningful tests:
http://chimper.org/rawloader-rustc-benchmarks/

Is there any downside to just aborting the second side of the join if the first side has already panic'ed and the second side is still waiting for a thread?

If we wanted to change our guarantees, yes, we could avoid starting the second side. You'd still be stuck if it already started though, so I'm not sure your DoS risk would be much reduced.

Surely if you're already in a panic situation you're not depending on results from the second operation?

We don't even give you the result of the non-panicking part, but it may still be important for its effects.

The try_for_each version works for the minimized test case but not for the actual code because the catch_unwind boundary limits what can be passed in to a closure.

You can assert its safety as long as you re-panic before any broken invariant might be visible. For example, here I have an atomic to short-circuit other work, then resume_unwind the guilty party.
    let quit = AtomicBool::new(false);
    out.par_chunks_mut(width).enumerate().try_for_each(|(row, _line)| {
        if quit.load(Ordering::SeqCst) {
            return None;
        }
        let result = panic::catch_unwind(AssertUnwindSafe(|| {
            panic!("panic at row {}", row)
        }));
        if let Err(payload) = result {
            quit.store(true, Ordering::SeqCst);
            panic::resume_unwind(payload);
        }
        Some(())
    });

But maybe we can find a nice API to wrap this concept, as @nikomatsakis suggests.

If we wanted to change our guarantees, yes, we could avoid starting the second side. You'd still be stuck if it already started though, so I'm not sure your DoS risk would be much reduced.

It's a race but since panic unwind is not particularly fast once you filled your CPUs it will probably end sooner. But not ideal, I agree.

We don't even give you the result of the non-panicking part, but it may still be important for its effects.

Right, my point was that if a part of the execution has already panic'ed you're unlikely to be relying on any effect from another part. Any thing sane you want to do there will almost surely require resetting to a sane state where everything has been thrown away. But maybe there are cases where that's not true.
A nice API would be great but unless I'm understanding something wrong this is actually enough:
extern crate rayon;
use self::rayon::prelude::*;
use std::panic;

fn main() {
    let width  = 10;
    let height = 10;

    let mut out: Vec<u16> = vec![0u16; width*height];
    match out.par_chunks_mut(width).enumerate().try_for_each(|(row, _line)| {
        panic::catch_unwind(panic::AssertUnwindSafe(|| panic!("panic at row {}", row)))
    }) {
        Err(_) => panic!("parallel execution panic'ed somewhere"),
        Ok(_)  => {},
    }
}

I can just use the handling of try_for_each to take care of stopping other threads and since I then launch a new panic everything is still safe, no?
Very preliminary testing shows this being either the same or even slightly faster than the previous code that only caught the panic much later in the stack. Maybe some optimization was unleashed from the panic handling happening in thread instead of having to cross threads. Will have to run a proper benchmark.

I can just use the handling of try_for_each to take care of stopping other threads and since I then launch a new panic everything is still safe, no?

I think that's OK, though I'm not fully versed in UnwindSafe -- I try to catch and rethrow ASAP to avoid thinking about it. :slightly_smiling_face:
Instead of your "somewhere" panic, you could also resume_unwind your Err case to make use of the real payload. Or just unwrap() that result, depending on how you want the backtrace to look, since a backtrace from inside the threadpool is often confusing.

Ah, resume_unwind makes sense indeed. So wouldn't @nikomatsakis wrapper be just:
fn for_each_shortcircuits_panic<OP>(self, op: OP)
where OP: Fn(Self::Item) + Sync + Send {
  match self.try_for_each(|item| {
    panic::catch_unwind(panic::AssertUnwindSafe(|| OP(item)))
  }) {
    Err(e) => panic::resume_unwind(e),
    Ok(_)  => {},
  };
}

With a better name somehow. Although if this benchmarks as fine wouldn't it just replace for_each?

I think the wrapper idea was that it would be part of the iterator chain, so it could work with anything, not just for_each.  e.g. foo.into_par_iter().fuse().map(|_| ...).collect()

Although if this benchmarks as fine wouldn't it just replace for_each?

I doubt its performance would be so transparent. LLVM can get very clever with the optimization of tight loops, and I expect catch_unwind will throw a giant wrench in there. If OP represents a large amount of work on each item, that overhead probably won't matter, but that's something the programmer should evaluate.

The filter does look good. I'll try and run some proper benchmarks.

Here's another version without explicitly catching anything:
struct Quitter<'a>(&'a AtomicBool);

impl Drop for Quitter<'_> {
    fn drop(&mut self) {
        self.0.store(true, Ordering::SeqCst);
    }
}

fn for_each_shortcircuits_panic<I, OP>(iter: I, op: OP)
where
    I: ParallelIterator,
    OP: Fn(I::Item) + Sync + Send,
{
    let quit = AtomicBool::new(false);

    iter.try_for_each(|item| {
        if quit.load(Ordering::SeqCst) {
            // There was already a panic somewhere
            None
        } else {
            // If we panic, the guard will set the bool on drop
            let guard = Quitter(&quit);
            op(item);

            // Otherwise forget the guard to leave the bool alone
            std::mem::forget(guard);
            Some(())
        }
    });

    // We'll never see quit==true; when it's set, we also resume the panic
    assert!(!quit.into_inner());
}

Cool. But isn't this now using two guard variables? One explicit and the other inside try_for_each?

Yeah, it's redundant. In a true iterator adaptor we can do better.

At least for my usage the catch_unwind inside the loop and resume_unwind outside is a very slight performance improvement:
http://scratch.corujas.net/rayon-iterator-panic-bench/
It's only 0.2-0.3% in total but some uncompressed formats (very fast inner loops) got up to 12% improvements:
http://scratch.corujas.net/rayon-iterator-panic-bench/version-try.html
That may mean I shouldn't be threading those at all, now that they're so fast. But somehow the panic catching actually improved the speed. Optimizing compilers are strange beasts I guess. The results are not just random variation as base and base2 are the same exact binary just to show what the natural variability of the test is. Each benchmark was ran 15 times and the median taken so noise was pretty well excluded.

I think we're now set with the available panic_fuse(). Users have the option to propagate panics sooner, at the cost of some extra synchronization.


[DO NOT MERGE] Auto PR to update dependencies of istio

This PR will be merged automatically once checks are successful.
none

@istio-testing: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
c43a8b8ce01d25e1dd969ddb3c608f4427ed8097
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


ProdMode: true seems not work on RC0

Short description of the problem:
I'm trying to enable production mode, as documented here but it seems not work.
I put in app.module.ts the following:
@NgModule({
  declarations: [
    MyApp,
    ...
  ],
  imports: [
    IonicModule.forRoot(MyApp, {
      backButtonText: 'Voltar',
      prodMode: true
    }),
    ChartsModule
  ],
  bootstrap: [IonicApp],
  ...
})

PS: I already tried to import enableProdMode, as below but nothing happens, I keep getting the following message

Angular 2 is running in the development mode. Call enableProdMode() to enable the production mode.

import { NgModule, enableProdMode } from '@angular/core';
What behavior are you expecting?
Enable the production mode.
Which Ionic Version? 1.x or 2.x
2.x RC0
Run ionic info from terminal/cmd prompt: (paste output below)
Cordova CLI: 6.3.1
Gulp version:  CLI version 3.9.1
Gulp local:
Ionic Framework Version: 2.0.0-rc.0
Ionic CLI Version: 2.1.0
Ionic App Lib Version: 2.1.0-beta.1
OS: Distributor ID:	Ubuntu Description:	Ubuntu 16.04.1 LTS
Node Version: v6.3.1

aren't you calling enableProdMode()?
import { NgModule, enableProdMode } from '@angular/core';

enableProdMode();

Thanka for response.
That way works, but why not this?
I saw that option prodMode in docs.
imports: [     IonicModule.forRoot(MyApp, {       backButtonText: 'Voltar',       prodMode: true     }),     ChartsModule   ]

@rafaelss95 right! I wanted to make sure enableProdMode() worked
Looks like, prodMode option was removed because the way the new NgModule works. I will go over this with my colleagues and get back to you.

could you update the docs to indicate how and where to enable prodmode now?  What file should the above suggested import and enable statement be in, and where in that file?  I have tried adding to app.component.ts but calling enableProdMode() in the constructur results in the app hanging, calling it anywhere after platform.ready results in cannot set prodmode after platform setup error.

@ghenry22 Just put it in app.module.ts.

sure I can put the imports in but where would you place the enableprodmode() call in that file given the current ionic2 base layout for that file?

You do not need to do anything for this anymore.
Production builds through app scripts will use the main.production.ts file which enables prodMode.

@mhartigton, I thought I had to import it in app.module.ts..

Nope, if you look at the main.prod.ts and the main.dev.ts
https://github.com/driftyco/ionic2-app-base/blob/master/src/app/main.prod.ts
https://github.com/driftyco/ionic2-app-base/blob/master/src/app/main.dev.ts
You can see that this is taken care of for you.

Hmm, I saw it now, but what file or what should we modify to enable production?

You do not need to do anything for this anymore.
It is automatically taken care of when you build for device.

Per my chat with @mhartington on Slack:
Production default:
> ionic build
> ionic run
Development default:
> ionic serve
And you can use --dev and --prod on each command.
e.g. > ionic build browser --dev.

@mhartington when invoking ionic build android --release the artifacts generated have .js.map in them. Is this the right way to create a production build ?


[crypto/otbn/sca] ecc256 device software for SCA

This PR is related to https://github.com/lowRISC/ot-sca/pull/115 in the ot-sca repository.
I fetched previous work from @jadephilipoom on ecc256 keygen and sign, which contains device software for SCA.
On top of that I edited the ecc256 keygen serial file to split loading of OTBN IMEM and DMEM, as discussed in the SCA WG meeting. This speeds up trace capture by ca. 10%.
In the future, when capturing traces for ecc256 sign, this modification probably has to be repeated.

After consultation with @jadephilipoom, this PR doesn't make any sense, as https://github.com/lowRISC/opentitan/pull/16953 already contains a lot of code which is also in this PR.
I'll merge my modifications into Jade's OT fork so that she can open another PR into the lowrisc repository.


Fetching data via store server side not working

Im sure this has been asked before but i cant for the life of me figure out whats going on
this code in the page
fetch ({ store }) {
 const response = await axios.get(dataUrl);
 console.log(response.data)
 store.commit("SET_SECTIONS", response.data);
}

and yet somehow this doesn't work
fetch ({store}) {
 store.dispatch('fetchSections')
}

where in the store the action is doing the same thing
 async fetchSections({ commit, getters }) {
    const response = await axios.get(dataUrl);
    console.log(response.data)
    commit("SET_SECTIONS", response.data);
  }

the console log is the same for both, but for some reason the one where the fetc calls the action isnt populating the store?
Any ideas?

Hi @keithmancuso, have you tried to use return in the second option?
fetch ({store}) {
 return store.dispatch('fetchSections')
}

Ahh interesting that fixed it, thanks for the quick response.
Although I'm not sure i understand why?

It's because fetch() can be or return a Promise :)

right!  thank you!


Dependabot wants to update Dockerfile.test in PR #7589

Dependabot wants to update Dockerfile.test in PR https://github.com/k3s-io/k3s/pull/7589

looks like we are skipping this version


1809 text needs to be finalized

The 1809 text still references skip ahead build. It needs to be updated to something like:
"Windows 10 October 2018 Update (link to https://blogs.windows.com/windowsexperience/2018/10/02/empowering-a-new-era-of-personal-productivity-with-new-surface-devices/ maybe, not really announce post for 1809) was originally released on October 2, 2019. Then on October 9, 2019 the roll-out was paused (link to https://blogs.windows.com/windowsexperience/2018/10/09/updated-version-of-windows-10-october-2018-update-released-to-windows-insiders/) due to issues with the build. A month later on November 13, 2019 (link to https://blogs.windows.com/windowsexperience/2018/11/13/resuming-the-rollout-of-the-windows-10-october-2018-update/). Windows Insiders helped test X builds.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: fa80910a-e655-34df-d26a-b094dd8702bb
Version Independent ID: 83b90d10-f455-fee5-cf94-2698f1ac33d6
Content: Flight Hub
Content Source: wip/flight-hub/index.md
Service: wip
GitHub Login: @lizap
Microsoft Alias: elizapo

@officedocsbot assign @mypil

@hoyty76  - Thank you for submitting feedback.
I will get this issue over to the Windows Insider writing team for investigation.
Thank you for reporting and making the docs better. Much appreciated.
I made a note to request the team to update this when the work is complete.

@hoyty76 Thanks for taking the time to submit helpful feedback. The article has been updated.

@hoyty76 - From our understanding, the issue has been resolved. If you feel it hasn't been resolved, please re-open this issue.
Thank you for your contribution to make the docs better! Much appreciated!

@officedocsbot close


Rename PSQLCodable to PostgresCodable

Motivation
Same as #224.
Modifications

Rename PSQLCodable to PostgresCodable
Rename PSQLEncodable to PostgresEncodable

Result
More consistent future API

Codecov Report

Merging #225 (02dd8b2) into main (77eb6c7) will increase coverage by 4.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #225      +/-   ##
==========================================
+ Coverage   39.10%   43.19%   +4.08%
==========================================
  Files         121      121
  Lines        9315     9322       +7
==========================================
+ Hits         3643     4027     +384
+ Misses       5672     5295     -377

Flag
Coverage Δ

unittests
43.19% <100.00%> (+4.08%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...s/PostgresNIO/New/Data/Array+PostgresCodable.swift
94.68% <ø> (ø)

...es/PostgresNIO/New/Data/Bool+PostgresCodable.swift
95.34% <ø> (ø)

...s/PostgresNIO/New/Data/Bytes+PostgresCodable.swift
73.52% <ø> (ø)

...es/PostgresNIO/New/Data/Date+PostgresCodable.swift
89.28% <ø> (ø)

...PostgresNIO/New/Data/Decimal+PostgresCodable.swift
74.19% <ø> (ø)

...s/PostgresNIO/New/Data/Float+PostgresCodable.swift
76.66% <ø> (ø)

...ces/PostgresNIO/New/Data/Int+PostgresCodable.swift
30.71% <ø> (ø)

...es/PostgresNIO/New/Data/JSON+PostgresCodable.swift
100.00% <ø> (ø)

...ostgresNIO/New/Data/Optional+PostgresCodable.swift
83.33% <ø> (ø)

...IO/New/Data/RawRepresentable+PostgresCodable.swift
82.35% <ø> (ø)

... and 35 more


nixos-unstable not being updated

Despite some new successful builds of nixos-unstable in the past week, the corresponding branch in the NixOS/nixpkgs-channels repository hasn't had any commits since 2016-08-10.

It happens sometimes that the channel doesn't update for no apparent reason; I don't know why.

It's due to https://github.com/NixOS/nixos-channel-scripts/commit/ab086b22efb4865c2b9180bff1d17aa46f64da70
To quote @edolstra from IRC:
15:17:49        niksnut | domenkozar: looks like the programs.sqlite generation is barfing                                                              │ alanz
15:17:50        niksnut | Aug 19 12:25:00 webserver update-nixos-unstable-small-start[30523]: error: this derivation has bad ‘meta.outputsToInstall’

So related to https://github.com/NixOS/nixos-org-configurations/commit/26989b60bb2b46ebd73ee3110bd54f3365a85156 then ?

Yes.

@edolstra: looks like you're the only one who usually pushes things to these these 2 repos.

Unstable still does not upgrade. Just realized that since August, 10th, all directories in http://nixos.org/releases/nixos/unstable/ have the string "-tmp" to their name.

Reopening as nixos-unstable seems to no longer be readable in https://nixos.org/channels/ (doesn't even show in directory listing)

That seems to be the only case. The others have today's timestamp and look OK (tested updating nixpkgs-unstable).

It will likely be fixed automatically when the next channel bump is initiated, but first we've got to fixup the remaining failures on Hydra.

@vcunat What is a channel bump? Is it when nixos-unstable gets changed to nixos-16.09?

Channel is back via some temporary hackery.

@despairblue: FTR I meant channel update, i.e. any change of its commit revision.

Happening again?

Possibly. Yesterday I thought it was a bit suspicious.

It seems to have disappeared from https://nixos.org/channels/ again. The previous time I checked, it was there but hadn't been updated since August.

It seems to be fixed now.

Is it happening again? nixos-unstable was lasted updated 2016-09-13 05:32, while nixos-unstable-small is a week newer at 2016-09-20 11:36.  I'd expect this hydra job to have hit the unstable channel by now.

There doesn't seem to be a nixos-unstable at https://nixos.org/channels/ at the moment. Same issue as before?

/cc @edolstra ^^

Hitting this problem right now.

It's back again (and hosted on S3).

@edolstra: this "broke" the link to unstable releases from bottom of http://nixos.org/nixos/download.html – the URL doesn't provide a directory listing now (noticed on IRC).

More problems in separate thread: https://github.com/NixOS/nixpkgs/issues/20735


Pass the error upon dispatch

Thanks for your pull-request @msqaddura! I've just released 0.9.1 with your change. Cheers!


Browserify: Error: Cannot find module 'react-big-calendar' from 'C:\Users\ernest\PhpstormProjects\reactcalendar'

Hi, I'm new on react and i'd like to install you component on my project. I installed you component, run the command browserify -t babelify index.js -o bundle.js but it gave me this error: Error: Cannot find module 'react-big-calendar' from 'C:\Users\ernest\PhpstormProjects\reactcalendar'. My .babelrc file look like this:
{   "presets": ["es2015", "react"] }
Can you help me to resolve the problem?

the error looks like it's in your code or build step... there isn't much for me to work on though here. make sure you installed the component from npm correctly and That your index. js kid requiring it correctly

I deleted the node_modules folder, reinstalled all the components with npm install and now it works!


Adjust to use of interpret module version 0.6

This commit bumped up interpret version to 0.6:
https://github.com/webpack/webpack/commit/bf3ea10f3cc988c78627498f81a188f796329e82#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R11
Because interpret changed the structure from 0.5 to 0.6 it made webpack stop working for me with webpack.config.coffee so I fixed the code that uses the interpret to behave in accordance to https://github.com/tkellen/js-interpret#how-to-use-it for version 0.6
Please accept the request quickly as the only thing I did to encounter the error was to install nodejs, webpack and coffee-script on clean machine and attempt to get something very basic working.
The bug also affects not only the people that like their webpack.config in different flavors of coffescript but also typescript, babel.js and jsx as you can infer from here: https://github.com/tkellen/js-interpret/blob/master/index.js

Thanks


Add declared license

Type: Missing
Summary:
Add declared license
Details:
The declared license on the source-archive was empty. The binary definition (https://clearlydefined.io/definitions/maven/mavencentral/com.microsoft.azure.iot/proton-j-azure-iot/0.12.2) has a declared license of "Apache-2.0". Further verified by going to Maven itself and checking the source package.
Resolution:
Source package: https://repo1.maven.org/maven2/com/microsoft/azure/iot/proton-j-azure-iot/0.12.2/proton-j-azure-iot-0.12.2-sources.jar
Path: META-INF\LICENSE
Affected definitions:

proton-j-azure-iot 0.12.2

Looked in the "Files" section on the ClearlyDefined definition.  License file is Apache-2.0
Pom indicates Apache-2.0
Conclusion:  Declared license is Apache-2.0


Implement Timsort

https://en.wikipedia.org/wiki/Timsort

@Eckankar
I will do it.
Thank You.

can i try this?

@Anmol-Sharma Go right ahead. :)


Simpify local image builds

Can you rename create_image_flavour.sh to create-image-flavor.sh. We have "OpenStack flavors" and I prefer to use - in filenames.

Can you rename create_image_flavour.sh to create-image-flavor.sh. We have "OpenStack flavors" and I prefer to use - in filenames.

Of cou(!)rse :-)

@scoopex Please rebase. Looks like this PR included the https://github.com/osism/node-image/commit/8a0fab5d98b1b698b90adf4c743f866564d84e0f.

@scoopex Please rebase. Looks like this PR included the 8a0fab5.

Done :-)


How to add other opponent in between an active P2P call.

Specify the sample to which the issue belongs (use [x]):
[x] P2P Call sample
Platform (use [x])
[x] Android
[x] iOS
Describe the bug:
How to add/join another opponent in between an active call like WhatsApp or Telegram.
Steps to Reproduce:

call from user 1 to user 2
now call from user 3 to user 2 or 1.
the call disconnects. even if I accept the new request

another way would be
when user 1 calls user 2 and after some time user 2 wants to join user 3 to the same call!
How to achieve this behaviour?

We didn't implement this functionality in our sample. For your case, user3 should know the 'roomId' for join to the call. Use our doc for implementing conference calls according to your needs. For simple checking (but not completely right) of joining an existing call, you can hardcode 'roomId' in the app, and in this case, all your users will join the same call. But this case usable only for tests, not for a production app, please study our documentation on how to implement the required features in the right way.

I am asking about the P2P calls, not the conference call. 🙂

sorry, I didn't note that you asked about P2P calls and thought that mean the conferences. Yes, it is not possible for P2P calls.


middleware/hsm: use blocking call over timeout (for now)

The serial package's max timeout is silently capped at 25.5s:
https://github.com/tarm/serial/blob/98f6abe2eb07edd42f6dfa2a934aea469acc29b7/serial.go#L158
We need longer for the blocking HSM operations to be able to finish.
We might add a shorter timeout and a repeater in the future, to still
abort after a (long) time, but unless we fully go async, all those
solutions are suboptimal.

haha, intresting take on timeouts.


Can info_card be clickable?

I’m wondering if it’s possible to make info_card clickable and make the key of info_card a output value?

no, you're welcome to create your own custom component,  or you could ask the $800M company to add a better clickable infocard component.


OrderBy gets overriden when used multiple times

1. Description
When OrderBy is used multiple times, only the last one is applied
3. Fiddle or Project
Simplified test cases
private class Sub( int mainId, int other )
{
	public int MainId { get; } = mainId;
	public int Other  { get; } = other;
}

// fail
[Fact]
public void OrderBy_multiple()
{
	// Arrange
	List<Sub> subList = [new Sub( 3, 1 ), new Sub( 1, 3 ), new Sub( 2, 2 )];

	// Act
	var query  = subList.AsQueryable().OrderBy( "Other" ).OrderBy( "MainId" );
	var result = query.ToList();

	// Assert
	result.ShouldBeInOrder( Shouldly.SortDirection.Descending, x => x.MainId );
}

// correct
[Fact]
public void OrderBy_single()
{
	// Arrange
	List<Sub> subList = [new Sub( 3, 1 ), new Sub( 1, 3 ), new Sub( 2, 2 )];

	// Act
	var query = subList.AsQueryable().OrderBy( "Other, MainId" );
	var result = query.ToList();

	// Assert
	result.ShouldBeInOrder( Shouldly.SortDirection.Descending, x => x.MainId );
}

would expect both versions to behave identical.
And here is the (simplified) real case
private class Main( int id )
{
	public int Id { get; } = id;
}

private class Sub( int mainId, int other )
{
	public int MainId { get; } = mainId;
	public int Other  { get; } = other;
}

[Fact]
public void OrderBy_outer_and_inner()
{
	// Arrange
	List<Main> mainList = [new Main( 2 ), new Main( 1 ), new Main( 3 )];
	List<Sub>  subList  = [new Sub( 3, 1 ), new Sub( 1, 3 ), new Sub( 2, 2 )];

	// Act
	IQueryable<Main> query = mainList.AsQueryable().Join(
			subList.AsQueryable(),
			outer => new { F1           = outer.Id },
			inner => new { F1           = inner.MainId },
			( outer, inner ) => new { o = outer, i = inner }
		)
		.OrderBy( "i.Other" )
		.Select( x => x.o )
		.OrderBy( "Id" );
	List<Main> result = query.ToList();

	// Assert
	result.ShouldBeInOrder( Shouldly.SortDirection.Descending, x => x.Id );
}

note: the inner part (join+order by) and outer part(order by) are done by different parts of the program.
note 2: the ShouldBeInOrder method is a custom extension, but i think you understand what result is expected
( behavior is identical with ef core queries )

If you have multiple OrderBy, you need to use ThenBy.
See
        public void ThenBy_Dynamic()

@StefH thanks for the fast response
this works for the simplified version - but it throws an exception in the real case example
System.InvalidOperationException
No generic method 'ThenBy' on type 'System.Linq.Queryable' is compatible with the supplied type arguments and arguments. No type arguments should be provided if the method is non-generic.
   at System.Linq.Expressions.Expression.FindMethod(Type type, String methodName, Type[] typeArgs, Expression[] args, BindingFlags flags)
   at System.Linq.Expressions.Expression.Call(Type type, String methodName, Type[] typeArguments, Expression[] arguments)
   at System.Linq.Dynamic.Core.DynamicQueryableExtensions.InternalThenBy(IOrderedQueryable source, ParsingConfig config, String ordering, IComparer comparer, Object[] args)
   at System.Linq.Dynamic.Core.DynamicQueryableExtensions.ThenBy(IOrderedQueryable source, ParsingConfig config, String ordering, Object[] args)
   at System.Linq.Dynamic.Core.DynamicQueryableExtensions.ThenBy[TSource](IOrderedQueryable`1 source, ParsingConfig config, String ordering, Object[] args)
   at System.Linq.Dynamic.Core.DynamicQueryableExtensions.ThenBy[TSource](IOrderedQueryable`1 source, String ordering, Object[] args)

updated complex example
[Fact]
public void OrderBy_outer_and_inner()
{
	// Arrange
	List<Main> mainList = [new Main( 2 ), new Main( 1 ), new Main( 3 )];
	List<Sub>  subList  = [new Sub( 3, 1 ), new Sub( 1, 3 ), new Sub( 2, 2 )];

	// Act
	IQueryable<Main> query = mainList.AsQueryable().Join(
			subList.AsQueryable(),
			outer => new { F1           = outer.Id },
			inner => new { F1           = inner.MainId },
			( outer, inner ) => new { o = outer, i = inner }
		)
		.OrderBy( "i.Other" )
		.Select( x => x.o );

	if( query is IOrderedQueryable<Main> orderedByQuery )
	{
		query = orderedByQuery.ThenBy( "Id" );
	}

	List<Main> result = query.ToList();

	// Assert
	result.ShouldBeInOrder( Shouldly.SortDirection.Descending, x => x.Id );
}

do you any suggestions how this can be achieved ? (as mentioned, the inner join+order part and the outer order part are done in different parts and doesnt know of each other

it seems that its not possible with the native OrderBy and Thenby either. Im currenlty waiting for an answer from the dotnet team, how this can be achieved and will keep this ticket updated

@puschie286 Can this question be closed?

yes - the dotnet team said it is by design. "Select" removes all ordering (except if its the last command), so you have to create an object with references to all related entities before applying all ordering and your final select.


Can't docker-compose up success

nohup.txt
npm install node-sass@latest ;  this command failed.

Client:
 Version:      18.03.1-ce
 API version:  1.37
 Go version:   go1.9.5
 Git commit:   9ee9f40
 Built:        Thu Apr 26 07:13:02 2018
 OS/Arch:      darwin/amd64
 Experimental: false
 Orchestrator: swarm

Server:
 Engine:
  Version:      18.03.1-ce
  API version:  1.37 (minimum version 1.12)
  Go version:   go1.9.5
  Git commit:   9ee9f40
  Built:        Thu Apr 26 07:22:38 2018
  OS/Arch:      linux/amd64
  Experimental: true

and another question, this config file ? i have do some change in docker-compose.yml, also need modified this config file ?

i have change npm to yarn, works fine, but meet some logs, seems my config with some error. who can help me ????
is it success?
jvb           | **** [cron] Enabling Cron
jvb           | [cont-init.d] 03-cron: exited 0.
jvb           | [cont-init.d] 04-smtp: executing...
jvb           | **** [smtp] Disabling SMTP Features
jvb           | [cont-init.d] 04-smtp: exited 0.
jvb           | [cont-init.d] 10-jitsi-videobridge: executing...
jicofo        |
jicofo        | ** [zabbix] Starting Zabbix Agent
jicofo        |
jicofo        | ** [jicofo] Sun Jul 15 23:48:33 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | [cont-init.d] 10-jitsi-videobridge: exited 0.
jvb           | [cont-init.d] 99-container-init: executing...
jvb           | [cont-init.d] 99-container-init: exited 0.
jvb           | [cont-init.d] done.
jvb           | [services.d] starting services
jvb           | [services.d] done.
jvb           |
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:48:35 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:48:43 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:48:45 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:48:53 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:48:55 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:49:03 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:49:05 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:49:14 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:49:15 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:49:24 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:49:25 PDT 2018 - Establishing connection with Prosody Host: prosody
jitsi-meet    | ** [cron] Starting cron
jicofo        | ** [cron] Starting cron
jicofo        | ** [jicofo] Sun Jul 15 23:49:34 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [cron] Starting cron
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:49:35 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:49:44 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:49:45 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:49:54 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:49:55 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:50:04 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:50:05 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:50:14 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:50:15 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:50:24 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:50:25 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:50:34 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:50:35 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Sun Jul 15 23:50:44 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Sun Jul 15 23:50:45 PDT 2018 - Establishing connection with Prosody Host: prosody
prosody       | WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
prosody       | [cont-init.d] 10-prosody: exited 0.
prosody       | [cont-init.d] 99-container-init: executing...
prosody       | [cont-init.d] 99-container-init: exited 0.
prosody       | [cont-init.d] done.
prosody       | [services.d] starting services
prosody       | [services.d] done.
prosody       |
prosody       | ** [zabbix] Starting Zabbix Agent
prosody       |
prosody       | ** [prosody] Registering Focus User
prosody       |
prosody       | ** [prosody] Starting prosody
jicofo        |
jicofo        | ** [jicofo] Starting jicofo
jvb           |
jvb           | ** [jitsi-videobridge] Starting jitsi-videobridge
prosody       | ** [cron] Starting cron

how to test ? and ....  oooooooooo....

Starting jitsi-meet ... done
Starting jvb        ... done
Starting jicofo     ... done
Attaching to jicofo, prosody, jitsi-meet, jvb
jicofo        | ** [cron] Starting cron
jicofo        |
jicofo        | ** [zabbix] Starting Zabbix Agent
jicofo        | ** [jicofo] Mon Jul 16 00:00:55 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
jicofo        | [s6-init] ensuring user provided files have correct perms...exited 0.
prosody       |
prosody       | ** [zabbix] Starting Zabbix Agent
prosody       | ** [cron] Starting cron
jicofo        | [fix-attrs.d] applying ownership & permissions fixes...
prosody       |
prosody       | ** [prosody] Starting prosody
jicofo        | [fix-attrs.d] 02-zabbix: applying...
prosody       | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
prosody       | [s6-init] ensuring user provided files have correct perms...exited 0.
jicofo        | [fix-attrs.d] 02-zabbix: exited 0.
jitsi-meet    |
jitsi-meet    | ** [zabbix] Starting Zabbix Agent
jicofo        | [fix-attrs.d] 03-logrotate: applying...
jicofo        | [fix-attrs.d] 03-logrotate: exited 0.
jicofo        | [fix-attrs.d] done.
jicofo        | [cont-init.d] executing container initialization scripts...
prosody       | [fix-attrs.d] applying ownership & permissions fixes...
prosody       | [fix-attrs.d] 02-zabbix: applying...
jicofo        | [cont-init.d] 01-permissions: executing...
jicofo        | [cont-init.d] 01-permissions: exited 0.
prosody       | [fix-attrs.d] 02-zabbix: exited 0.
jicofo        | [cont-init.d] 02-zabbix: executing...
jitsi-meet    |
jitsi-meet    | ** [jitsi-meet] Starting nginx
jitsi-meet    | ** [cron] Starting cron
jicofo        | [cont-init.d] 02-zabbix: exited 0.
jitsi-meet    | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
jitsi-meet    | [s6-init] ensuring user provided files have correct perms...exited 0.
prosody       | [fix-attrs.d] 03-logrotate: applying...
jvb           |
jvb           | **** [zabbix] Starting Zabbix Agent
jicofo        | [cont-init.d] 03-cron: executing...
prosody       | [fix-attrs.d] 03-logrotate: exited 0.
prosody       | [fix-attrs.d] done.
jvb           | ** [cron] Starting cron
jicofo        | **** [cron] Enabling Cron
jicofo        | [cont-init.d] 03-cron: exited 0.
jvb           | [s6-init] making user provided files available at /var/run/s6/etc...** [jitsi-videobridge] Mon Jul 16 00:01:01 PDT 2018 - Establishing connection with Prosody Host: prosody
prosody       | [cont-init.d] executing container initialization scripts...
jitsi-meet    | [fix-attrs.d] applying ownership & permissions fixes...
jvb           | exited 0.
prosody       | [cont-init.d] 01-permissions: executing...
prosody       | [cont-init.d] 01-permissions: exited 0.
jitsi-meet    | [fix-attrs.d] 02-zabbix: applying...
jicofo        | [cont-init.d] 04-smtp: executing...
jicofo        | **** [smtp] Disabling SMTP Features
jicofo        | [cont-init.d] 04-smtp: exited 0.
jicofo        | [cont-init.d] 10-jicofo: executing...
jicofo        | [cont-init.d] 10-jicofo: exited 0.
jitsi-meet    | [fix-attrs.d] 02-zabbix: exited 0.
prosody       | [cont-init.d] 02-zabbix: executing...
jitsi-meet    | [fix-attrs.d] 03-logrotate: applying...
jicofo        | [cont-init.d] 99-container-init: executing...
jicofo        | [cont-init.d] 99-container-init: exited 0.
jicofo        | [cont-init.d] done.
jicofo        | [services.d] starting services
jicofo        | [services.d] done.
prosody       | [cont-init.d] 02-zabbix: exited 0.
jitsi-meet    | [fix-attrs.d] 03-logrotate: exited 0.
jitsi-meet    | [fix-attrs.d] done.
jitsi-meet    | [cont-init.d] executing container initialization scripts...
prosody       | [cont-init.d] 03-cron: executing...
prosody       | **** [cron] Enabling Cron
prosody       | [cont-init.d] 03-cron: exited 0.
prosody       | [cont-init.d] 04-smtp: executing...
prosody       | **** [smtp] Disabling SMTP Features
prosody       | [cont-init.d] 04-smtp: exited 0.
jitsi-meet    | [cont-init.d] 01-permissions: executing...
prosody       | [cont-init.d] 10-prosody: executing...
jitsi-meet    | [cont-init.d] 01-permissions: exited 0.
jitsi-meet    | [cont-init.d] 02-zabbix: executing...
jitsi-meet    | [cont-init.d] 02-zabbix: exited 0.
prosody       | Certificates already exist, skipping..
jitsi-meet    | [cont-init.d] 03-cron: executing...
prosody       | ln: /etc/prosody/certs/<IP_ADDRESS>.crt: File exists
prosody       | ln: /etc/prosody/certs/<IP_ADDRESS>.key: File exists
jitsi-meet    | **** [cron] Enabling Cron
prosody       | ln: /etc/prosody/certs/auth.<IP_ADDRESS>.crt: File exists
prosody       | ln: /etc/prosody/certs/auth.<IP_ADDRESS>.key: File exists
jitsi-meet    | [cont-init.d] 03-cron: exited 0.
prosody       | WARNING: ca-certificates.crt does not contain exactly one certificate or CRL: skipping
prosody       | [cont-init.d] 10-prosody: exited 0.
jitsi-meet    | [cont-init.d] 04-smtp: executing...
jitsi-meet    | **** [smtp] Disabling SMTP Features
prosody       | [cont-init.d] 99-container-init: executing...
prosody       | [cont-init.d] 99-container-init: exited 0.
prosody       | [cont-init.d] done.
prosody       | [services.d] starting services
prosody       | [services.d] done.
jitsi-meet    | [cont-init.d] 04-smtp: exited 0.
jitsi-meet    | [cont-init.d] 10-nginx: executing...
jitsi-meet    | [cont-init.d] 10-nginx: exited 0.
jitsi-meet    | [cont-init.d] 99-container-init: executing...
jitsi-meet    | [cont-init.d] 99-container-init: exited 0.
jitsi-meet    | [cont-init.d] done.
jitsi-meet    | [services.d] starting services
jitsi-meet    | [services.d] done.
jvb           | [s6-init] ensuring user provided files have correct perms...exited 0.
jvb           | [fix-attrs.d] applying ownership & permissions fixes...
jvb           | [fix-attrs.d] 02-zabbix: applying...
jvb           | [fix-attrs.d] 02-zabbix: exited 0.
jvb           | [fix-attrs.d] 03-logrotate: applying...
jvb           | [fix-attrs.d] 03-logrotate: exited 0.
jvb           | [fix-attrs.d] done.
jvb           | [cont-init.d] executing container initialization scripts...
jvb           | [cont-init.d] 01-permissions: executing...
jvb           | [cont-init.d] 01-permissions: exited 0.
jvb           | [cont-init.d] 02-zabbix: executing...
jvb           | **** [zabbix] Disabling Zabbix
jvb           | [cont-init.d] 02-zabbix: exited 0.
jvb           | [cont-init.d] 03-cron: executing...
jvb           | **** [cron] Enabling Cron
jvb           | [cont-init.d] 03-cron: exited 0.
jvb           | [cont-init.d] 04-smtp: executing...
jvb           | **** [smtp] Disabling SMTP Features
jvb           | [cont-init.d] 04-smtp: exited 0.
jvb           | [cont-init.d] 10-jitsi-videobridge: executing...
jvb           | [cont-init.d] 10-jitsi-videobridge: exited 0.
jvb           | [cont-init.d] 99-container-init: executing...
jvb           | [cont-init.d] 99-container-init: exited 0.
jvb           | [cont-init.d] done.
jvb           | [services.d] starting services
jvb           | [services.d] done.
jicofo        | ** [jicofo] Mon Jul 16 00:01:05 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Mon Jul 16 00:01:11 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Mon Jul 16 00:01:15 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Mon Jul 16 00:01:21 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Mon Jul 16 00:01:25 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Mon Jul 16 00:01:31 PDT 2018 - Establishing connection with Prosody Host: prosody
jicofo        | ** [jicofo] Mon Jul 16 00:01:35 PDT 2018 - Establishing connection with Prosody Host: prosody
jvb           | ** [jitsi-videobridge] Mon Jul 16 00:01:41 PDT 2018 - Establishing connection with Prosody Host: prosody

compose file:
version: '2'

services:
  prosody:
    build: ../prosody
    container_name: prosody
    image: prosody
    volumes:
      - ./logs/prosody:/var/log/prosody
      - ./certs:/certs

    environment:
      - HOST=<IP_ADDRESS>

      - JITSI_VIDEO_PASS=dylanccccc
      - JICOFO_PASS=dylanccccc
      - JICOFO_USER_PASS=dylanccccc
    networks:
      - proxy-tier
    restart: always

  jicofo:
    build: ../jicofo
    container_name: jicofo
    image: jicofo
    volumes:
      - ./logs/jicofo:/var/log/jitsi
      - ./certs:/certs

    environment:
      - PROSODY_HOST=prosody
      - HOST=<IP_ADDRESS>

      - JICOFO_PASS=dylanccccc
      - JICOFO_USER_PASS=dylanccccc
    networks:
      - proxy-tier
    restart: always

  jvb:
    build: ../jvb/debian
    container_name: jvb
    image: jvb
    ports:
      - 4443:4443
      - 10000-10100/udp
    volumes:
      - ./logs/jvb:/var/log/jitsi
      - ./certs:/certs

    environment:
      - HOST=<IP_ADDRESS>
      - PROSODY_HOST=prosody
      - ENABLE_ZABBIX=FALSE
      - JITSI_VIDEO_PASS=dylanccccc

      - NETWORK_MODE=NAT

    networks:
      - proxy-tier
    restart: always

  jitsi-meet:
    build: ../jitsi-meet
    container_name: jitsi-meet
    image: jitsi-meet
    volumes:
      - ./assets/jitsi-meet:/assets/jitsi-meet
      - ./logs/nginx:/var/log/nginx
      - ./certs:/certs
    environment:
      - VIRTUAL_HOST=<IP_ADDRESS>
      - VIRTUAL_NETWORK=nginx-proxy
      - LETSENCRYPT_HOST=<IP_ADDRESS>
      -<EMAIL_ADDRESS>
      - JITSI_VIDEO_PASS=dylanccccc
      - JICOFO_PASS=dylanccccc
      - JICOFO_USER_PASS=dylanccccc

      - PROSODY_HOST=prosody

    networks:
      - proxy-tier
    restart: always

networks:
  proxy-tier:
    external:
      name: nginx-proxy


Minimal evdev implementation (directions + Enter)

Issue #13

AUTHORS file should also be updated. Thanks 👍

Cool to see improvements to this code, thanks @peterhellberg 👍

We should also run tests for all packages under ./sense/...
(Currently trying to fix a race-condition between d.Close() and d.pollEvents(), will update .travis.yml when I’ve solved that issue)

Since the device file is opened in Read-Only mode, there doesn’t seem to be a reason for closing it before the kernel/runtime closes it after main ends.
Are you happy with me merging this pull request now?

Thanks @peterhellberg. I'll try it out again this weekend and get it merged.

Whoops. I didn't get to this on the weekend. :-(

No worries, I was in Paris for dotGo anyway :)
On Wednesday, 12 October 2016, Nathan Youngman<EMAIL_ADDRESS>wrote:

Whoops. I didn't get to this on the weekend. :-(
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nathany/bobblehat/pull/14#issuecomment-253272188, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAifhOK6OjvtjAUQi7YcilnT9Sg-hcnLks5qzRD8gaJpZM4KFsH7
.

--
--
Peter Hellberg
Go and Ruby Developer, Code7 Interactive

@nathany Did you get a chance to look at this PR?

Sorry for the delay. I'm looking at it now. (First Saturday of the month is a hack day here, and I brought my Pi).


ui: show password with success notification

Description
Fixes #5888

Types of changes

[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] New feature (non-breaking change which adds functionality)
[x] Bug fix (non-breaking change which fixes an issue)
[ ] Enhancement (improves an existing feature and functionality)
[ ] Cleanup (Code refactoring and cleanup, that may add test cases)

Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale

[ ] Major
[ ] Minor

Bug Severity

[ ] BLOCKER
[ ] Critical
[ ] Major
[ ] Minor
[ ] Trivial

Screenshots (if appropriate):

How Has This Been Tested?

@blueorangutan ui

@shwstppr a Jenkins job has been kicked to build UI QA env. I'll keep you posted as I make progress.

UI build: :heavy_check_mark:
Live QA URL: http://qa.cloudstack.cloud:8080/client/pr/5889 (SL-JID-1056)


Bug in protocol imports

See https://github.com/GoalSmashers/clean-css/issues/85#issuecomment-32083966
cleanCss = require('clean-css');
inst = new cleanCss;
inst.minify('@import url("//fonts.googleapis.com/css?family=Oleo Script Swash Caps");\n.block2 { font-family: \'Oleo Script Swash Caps\'; }\n');

resolves into
@import url(//fonts.googleapis.com/css?family=Oleo) Script Swash Caps);.block2{font-family:'Oleo Script Swash Caps'}

It might be a good idea to leave the ticket open until it has been fixed on 2.1?
Especially for new users having the same issue to find this one.

I am still having the same issue… with the latest version, can someone replicate it?

@zanona Works for me with the latest 3.0. Does that help anyhow? https://github.com/jakubpawlowicz/clean-css#how-to-make-sure-remote-imports-are-processed-correctly

thanks for your reply @jakubpawlowicz,
The problem here lies on the correct behaviour that generates a new one, I guess, when using relative protocols:
var CleanCSS = require('clean-css');
var source = '@import url(//fonts.googleapis.com/css?family=Archivo+Narrow);'
new CleanCSS().minify(source, function (errors, minified) {
  console.log(minified.styles);
});

Formatted response here is:
@font-face {
    font-family: 'Archivo Narrow';font-style:normal;font-weight:400;
    src: local('Archivo Narrow Regular'),
         local('ArchivoNarrowRegular'),
         url(http://fonts.gstatic.com/s/archivonarrow/v5/…ttf) format('truetype')
}

In this case, please note that since relative was used, its usage should be able to work on both protocols, (http or https), when requesting those by https, the code generated by google automatically converts protocols included for https.
I understand that since the initial imported file is merged within the output, the protocol doesn't matter anymore, but just for safety, I believe it might be best to first perform the import with a HTTPS request first when relative protocol is used, making sure the script will work on both when deployed.
Also, may I ask what happens in case inside the imported document there is another CSS import statement? does Clean CSS follow those URLs as well?
Cheers

@zanona I think we may do something about it indeed, ideally defaulting back to no protocol for URLs.
However defaulting to http is usually safer as 1) it's more widespread 2) it gets redirected to HTTPS but rather not the other way around 3) in case your site uses HSTS it will get resolved to HTTPS automatically.
Let me open another ticket to support defaulting URLs to no-protocol.
Re your last question clean-css supports recurring imports as well.

Opened as #448.


Link to Lukasz' specific analysis on visited links.

This is meant to fix #174 by @lflores-ms, by linking to the article that shows the :visited attack. Another way to fix it might be to generalize the claim about Ambient Light to include the potential attacks described on the main page. Thoughts?

Preview | Diff

Thanks @jyasskin for linking to the relevant post. I think that the specific example of visited links through Ambient Light Sensor API helps drive the point about risk in these APIs in a more concrete manner.


[Feature Request] Multi-Tab Charactersheets

Using Charactersheets in fullscreen is neat, but also would allow for further productivity, if the charactersheet allows for multiple (or two) tabs.

(This is just a design-edit)
Maybe allow rightclicking for the second tab or something?
Visibility which tab is which could be done with colored tab outlines?

Thanks for the suggestion, and thank you for trying out the sheets!
I agree that these sheets could use some more flexibility with tabs and displaying information on the screen. I am interested in enhancing the wider display experience in the future. It may have to come after a great deal of compatibility efforts, some other features upgrades, and going v1 (taking over the official Tidy 5e package in Foundry), so it could be a while, but in time, I will be able to come back to this open issue and begin planning some kind of support for more advanced visualizing of sheet info at wider views.


Unwrap Lists in deparse instead of preparsing the AST + remove lodash

This cuts total runtime of our internal test suite by 38%.
Summary of changes:

use unwrapList to attempt to extract the array inside the List, any time we attempt to do array operations
Combine regexes into single regex and cache it
Make reserved words a set
Drop lodash in favor of built-ins
Remove usages of object/array spread and destructuring to reduce babel helpers
Remove usage of dotty.exist, which didn't provide much help relative to cost in the few places used

With the above, we can remove preparse.js
Closes #97

Thanks @benasher44 ! this is great

@pyramation one thing to consider is downstream libpg_query has deparse now, starting with postgres 13. do you think it's possible to use it? If so, that could reduce library maintenance here to automatic maintenance of symmetric versions + maintaining the build

So, I'm open to it! But I'd prefer making another package, perhaps, native-deparse, because currently the deparse package doesn't rely on any C code or the postgres build. The current deparse is pure javascript which makes it super portable.

Btw, I'm merging into a develop branch so I can run tests, for some reason the testing CI didn't run with this PR.

https://github.com/pyramation/pgsql-parser/actions/runs/4421396540/jobs/7752144298

Awesome thanks!

Thanks @benasher44 ! this is great

@pyramation one thing to consider is downstream libpg_query has deparse now, starting with postgres 13. do you think it's possible to use it? If so, that could reduce library maintenance here to automatic maintenance of symmetric versions + maintaining the build

So, I'm open to it! But I'd prefer making another package, perhaps, native-deparse, because currently the deparse package doesn't rely on any C code or the postgres build. The current deparse is pure javascript which makes it super portable.

That's fair. We may look into it, and if we open a PR, we'll make it a separate package then. Are people making SQL ASTs without going through the parser (which relies on C code)?


d3.interpolators bug

in case there is a =NaN and b is object, d3.interpolators will anyway evaluate it as d3_interpolateObject  and will subsequently fail there in if (!(k in a)) ... "Invalid Operand to 'in' : Object expected.
proposed fix that works for me was to add test for 'a' as object too on this line:
https://github.com/mbostock/d3/blob/master/src/interpolate/interpolate.js#L23
d3.interpolators = [ function(a, b) {
      var t = typeof b;
      return  (t === "string" ? (d3_rgb_names.has(b.toLowerCase()) || /^(#|rgb\(|hsl\()/i.test(b) ? d3_interpolateRgb : d3_interpolateString)
               : b instanceof d3_color ? d3_interpolateRgb
               : Array.isArray(b) ? d3_interpolateArray
               : t === "object" && isNaN(b)  && typeof a === "object" && isNaN(a) ? d3_interpolateObject
               : d3_interpolateNumber)(a, b);
  } ];

v d3-3.5.12.

The interpolator is supposed to be chosen entirely based on the target value, b. So the problem is that interpolateObject isn’t coercing the starting value to an object. I’ll file a bug in d3-interpolate.

This was fixed in d3-interpolate 0.4.