Is it possible have code completion navigation et al in omnisharp-vscode without .NET framework installed?

Environment data
dotnet --info output:
.NET Command Line Tools (2.0.3)
Product Information:
Version:            2.0.3
Commit SHA-1 hash:  12f0c7efcc
Runtime Environment:
OS Name:     Windows
OS Version:  10.0.14393
OS Platform: Windows
RID:         win10-x64
Base Path:   [omitted-contains personal info]
Microsoft .NET Core Shared Framework Host
Version  : 2.0.3
Build    : a9190d4a75f4a982ae4b4fa8d1a24526566c69df
VS Code version:  1.18.1
C# Extension version: 1.13.1
My first question was here but I think that I've asked the wrong question so I didn't get the expected answers.
My problem is described in this stackoverflow question. For convenience I will paste it here. The problem with .NET CLI was solved. The most important one with the "Reference Assemblies" remains.
I have a C# solution (plain ol' sln files) with several csproj projects. I just want to setup a powerful code editor that can support for example "go to declaration" navigation on computers with the following restrictions:

I don't have administrative rights to and
they don't have .NET framework SDK installed or .NET CLI

So for starters I've downloaded the portable version, I've added the C# plugin, I've added the dependencies manually after following this excellent post of Dustin Campbell and now I have the following problems every time I open the project folder:

I get the message The .NET CLI tools cannot be located. .NET Core debugging will not be enabled. Make sure .NET CLI tools are installed and are on the path. I'm fine with that since I'm not interested in debugging and running; just mentioning for the sake of completeness.
I get a warning that Some projects have trouble loading and I see in the output this message:

fail: OmniSharp.MSBuild.ProjectFile.ProjectFileInfo

The reference assemblies for framework ".NETFramework,Version=v4.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

So the first thing I tried was to hack my way around this and see if I could make it work just by dropping the correct reference assemblies into C:\Program Files\Reference Assemblies\Microsoft\Framework\ according to this answer. But then Bazinga! I don't have administrative rights to do that.
So my question is, can somebody use VS code as a powerful code editor without administrator rights, or I'm just chasing windmills?
Just to make my self clear, I don't care about the error message as long as I have navigation, autocompletion and refactoring capabilities in omnisharp-vscode.

@adamstyl Can you share the contents of C:\Program Files (x86)\Reference Assemblies\microsoft\Framework\.NETFramework? It sounds like one of the projects you're trying to edit targets .NET Framework v4.0 but you don't have the targeting pack installed. If that's the case, I think you can do as suggested in this StackOverflow post (https://stackoverflow.com/questions/44006035/target-net-4-7-without-installing-the-targeting-pack) and use the FrameworkPathOverride property in your csproj to load reference assemblies from a different directory.

@adamstyl : @rchande is correct. C# for VS Code uses MSBuild to locate the correct reference assemblies on your machine. It's likely that you need to install the .NET Framework 4.0 developer pack in order to get them on your machine (I wouldn't go copying things around and hoping they work). Try grabbing the latest .NET Framework Developer Pack from https://www.microsoft.com/net/download/visual-studio-sdks.

Also, could you provide your complete OmniSharp Log? You can retrieve this by selecting View->Output from the VS Code menu and then choosing "OmniSharp Log" from the drop-down in the top-right corner of the Output pane.

Hello everyone and thanks for helping out on this.
@rchande There is no need to share them, I know that the problem is there! :D Sorry for considering it obvious. There is no .NETFramework subdirectory for me. Under C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework there is only v3.0 and v3.5. Obviously the 4.0 is missing :)
The FrameworkPathOverride worked. I tried it for one csproj and that project was loaded normally. No fail in output and autocomplete was working just fine. The problem is that this is cumbersome, as every time I will have to change >20 csproj files :(
@DustinCampbell unfortunately I don't have administrative access to perform any installations :( Yes I know, I could ask the administrator to do it. But what I'm trying to do is exactly that: have a powerful C# editor without the need of elevated privileges. What if I have the code on a random machine, I can run VS code and I am in desperate need to do it now? Admins might not be able to do the installation right now. They might not even be available at that day and time. So I need a "war time" solution.
Do you still need the OmniSharp Log output? It's quite big, 216 lines. I don't think it would be beneficial to add it here... The [fail:] OmniSharp.MSBuild.ProjectFile.ProjectFileInfo that I've quoted is from OmniSharp Log output, just imagine it repeating ~20 more times, one for every csproj I have in there :D
What I was thinking is something similar to what Jetbrains Rider does: I've extracted the EAP version from the zip, run the exe, loaded the same sln on the same machine and that was it. I was having autocomplete, navigation, even error reporting without having a .NET framework installation. I'm not saying it was perfect, it was handy though. I guess this is done by leveraging Roslyn, but then I'm not sure if I have to look into other VS code plugins like for example omnisharp-roslyn? But as I said, I don't know since I'm just guessing how Rider works. If you have any thoughts or ideas please share.

@adamstyl : This is likely not done using Roslyn since JetBrains Rider doesn't use it and we do. :smile: The real issue here is around having a bit more leniency when MSBuild fails to process your project. We could add support for "limping along", but you'd see a ton of error squiggles from types not being resolved. FWIW, Visual Studio would have the same problem.

@adamstyl : I can't speak for Rider. It's possible that they install reference assemblies themselves, but I don't really have a way of knowing. (Full disclosure: I'm a Microsoft employee working on the C# team.)

@DustinCampbell yes I can imagine that, the question was mostly rhetorical, I guess there won't be anybody willing to answer it for obvious reasons! 😄
Is there a way to apply the FrameworkPathOverride solution wide? Otherwise I should close this issue 😃

pressed the wrong button...

You could try using a Directory.Build.props file. https://docs.microsoft.com/en-us/visualstudio/msbuild/customize-your-build

@DustinCampbell Thanks again, I will test tomorrow and post feedback.

@DustinCampbell worked like a charm. I have everything now (navigation to types works, code completion works).
There is a small hiccup though, I get a The type 'Func<TResult>' exists in both 'System.Core, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089' and 'mscorlib, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b77a5c561934e089' message which doesn't happen (I think) on a machine with a properly installed .NET
But I guess that this is what you get when you try to make things work with hacks 😃
Thanks again everyone for helping out, I'm now closing the issue.


It was a cross-thread update,

Describe the bug and how we can reproduce it.
// a code sample may improve communication
```System.InvalidOperationException: 对象当前正在其他地方使用。
   在 System.Drawing.Image.get_FrameDimensionsList()
   在 System.Drawing.ImageAnimator.CanAnimate(Image image)
   在 System.Drawing.ImageAnimator.ImageInfo..ctor(Image image)
   在 System.Drawing.ImageAnimator.Animate(Image image, EventHandler onFrameChangedHandler)
   在 System.Windows.Forms.PictureBox.Animate(Boolean animate)
   在 System.Windows.Forms.PictureBox.Animate()
   在 System.Windows.Forms.PictureBox.InstallNewImage(Image value, ImageInstallationType installationType)
   在 System.Windows.Forms.PictureBox.set_Image(Image value)
   在 ScottPlot.FormsPlot.Render(Boolean skipIfCurrentlyRendering, Boolean lowQuality, Boolean recalculateLayout)
位置 E:\\AcquisitionFrame\ScottPlot-master\src\ScottPlot.WinForms\FormsPlot.cs:行号 108
   在 AcquisitionFrame.View.Panels.OP1130_P10.tPlot(AutoResetEvent& Stop)

Hi @ZTaiIT1025, thank you for reporting this!
I think 对象当前正在其他地方使用 means Object is currently being used elsewhere. Can you share the WinForms code that reproduces this error?
My guess is that you are replacing the xs or ys field of a ScatterPlot. This is not recommended because it is not thread safe (you could be plotting a variable in one thread, then replace it in another). If you are doing this, a better solution is to replace the elements inside an array instead of replacing the array itself.

My array is growing and updated in real time on another thread

Hi @ZTaiIT1025,
Code you provided running on UI Thread?
This line:
  formsPlot1.Render(skipIfCurrentlyRendering: true);

must be invoked on UI tread, and exception  looks like you try to update UI from another thread.
Try to replace this line with:
formsPlot1.Invoke((MethodInvoker)delegate {
    // Running on the UI thread
    formsPlot1.Render(skipIfCurrentlyRendering: true);
});

I'll try，But Does this block the UI thread？

Defining the Issue
I don't have a great solution yet, but this is what I learned while investigating this:

The Render() method makes many calls to the list of plottables. An InvalidOperationException is thrown when the list of plottabes is modified in the middle of a render.

This means plottables can not be added or removed while rendering may be occurring in another thread. It is not easy to control when rendering happens because mouse interactions and window resizing can trigger rendering at unpredictable times.

One way to fix this is to only add or remove plottables in your UI thread. Since both operations block the UI thread, they won't occur simultaneously. Note that this does not have to be slow because you can do your logic in another thread, but at the end when it's time to call PlotScatter() you could do that in your UI thread.

Recreating the Issue
I recreated this issue (or a similar one) with a unit test that fails on my system ~90% of the time.
[Test]
public void Test_Concurrent_ModifyPlottablesWhileRendering()
{
	var plt = new ScottPlot.Plot();
	var bmp = new System.Drawing.Bitmap(300, 200);

	// update plottables continuously in the background
	Thread updateThread = new Thread(new ParameterizedThreadStart(ContinuouslyModifyPlottables));
	updateThread.Start(plt);

	// render repeatedly while the plottalbles are being modified
	var sw = Stopwatch.StartNew();
	while (sw.ElapsedMilliseconds < 5000)
	{
		plt.Render(bmp);
	}

	ContinueModifyingPlottables = false;
	updateThread.Join();

	Console.WriteLine("Test complete");
	Assert.Pass();
}

public static bool ContinueModifyingPlottables = true;
public static void ContinuouslyModifyPlottables(object data)
{
	ScottPlot.Plot plt = (ScottPlot.Plot)data;
	while (ContinueModifyingPlottables)
	{
		plt.Clear();
		plt.PlotSignal(new double[] { 1, 2, 3 });
	}
	Debug.WriteLine("Modification thread shutting down...");
	Thread.Sleep(100);
}

  Message:
    System.InvalidOperationException : Collection was modified; enumeration operation may not execute.
  Stack Trace:
    Enumerator.MoveNextRare()
    WhereSelectListIterator`2.MoveNext()
    WhereSelectEnumerableIterator`2.ToArray()
    Settings.AxisAutoX(Int32 xAxisIndex, Double margin, Boolean expandOnly) line 203
    Settings.AxisAutoUnsetAxes() line 171
    Plot.Render(Bitmap bmp, Boolean lowQuality) line 35
    ConcurrencyTests.Test_Concurrent_ModifyPlottablesWhileRendering() line 38

Solution?
I don't have a great solution yet, but these are some ideas:
Perhaps copying the list of plottables before a render would help. Technically this is not perfect because other things (like axes) could be modified mid-render. The the whole settings module could be deeply copied on every render, but that seems burdensome and slow.
Perhaps some type of lock mechanism could be used to prevent plottables or axes from being added until a render finishes.
while (formsPlot1.plt.IsRendering) { /* wait */ }
formsPlot1.plt.Clear();
formsPlot1.plt.PlotScatter(newXs, newYs);

I added a Plot.IsRendering field (5a8ba5c), and I found that waiting for it to go false before (quickly) modifying the plot seems to fix this issue!
Note that my change just now is in the master branch which is currently a pre-release version of ScottPlot 4.1. If you want to make a similar change to the 4.0 source code you can obtain that from https://github.com/swharden/ScottPlot/releases
An alternative (and perhaps more thorough) option is to modify the user control code and wrap the contents of Render() with a try/catch block. This way you can ensure the user control never throws a render error.

@ZTaiIT1025 and @StendProg I created a system which I think solves this issue... but I'm interested in your input. I'll release this on NuGet tonight in version 4.0.45
If you want to modify the plot from another thread you can call RenderLock() and this will wait for the current render to finish, then prevent future renders from occurring. This lets you make your plot modifications in another thread (e.g., replacing a data array). After your modifications are done, call RenderUnlock() to allow renders to proceed. If a render was requested while the lock was enabled, it will resume immediately after the lock is released.
I think RenderLock() is a dangerous function because it could freeze your application if called from the wrong thread... However, I think its name looks dangerous, and together with and a descriptive XML doc this is enough to ensure it does not get used by accident.
I created a little WinForms app to test it and I think it's working properly:
https://github.com/swharden/ScottPlot/blob/e4d5c87751bba3352fce62cea42828d0787702cb/dev/FormsPlotSandbox/FormSandbox.cs#L14-L57

Thanks


speed up watch list crossmatching

Just pinning this for the future. I think I/we can significantly increase the crossmatching speed.

I've added a new drop-in replacement script for run_crossmatch.py called run_crossmatch_optimise.py. It can be found on lasair-ztf-web at ~/lasair4/utility.
Here are some comparison run times for matching a small(ish) and large watchlist against the full ZTF database.
time python3 run_crossmatch.py 139
vs
time python3 run_crossmatch_optimsed.py 139

Watchlist ID
Source Count
Results
Current Match Time
Optimised Match Time

1175  (Milliquas)
1021800
127126 hits
55m37s
1m49s

139 (E+A galaxies)
51907
870 hits
2m52s
5s

So, it is roughly 30 times faster :)
If you're happy, I can prepare a pull request.

Dave -- this looks fabulous! But I worry about all the dependencies, the fundamentals, the Humpty, the use of a custom logging instead what the rest of Lasair uses. Can you point me to the code and documentation for conesearch:
from HMpTy.mysql import conesearch

Thanks!

Hi Roy, HMpTy and Fundamentals are my codes, so they are within our control. Here are the HMpTy docs:
https://hmpty.readthedocs.io/en/master/
You will see I am passing an empty (i.e. dummy) logger as Lasair does not use the standard Python logging much.

Hi Roy,
Sure thing, I'll be there. We can discuss the button logic at the meeting :)


Firing queries from Android Studio plugin with @nonull directive

Question
Hey, I am using Apollo plugin with Android Studio and I used to test my graphql files directly from IDE. Noticed that adding @nonull does not allow plugin to work and returns error message "message": "directive 'nonnull' is not defined in the schema"
The question is if that can be somehow workaround?

Can you try enabling the "Apollo Kotlin" framework in the GraphQL plugin?

Hey @martinbonnin I had this enabled

IDE support is still being worked on (see https://github.com/JetBrains/js-graphql-intellij-plugin/issues/697) so it'll come but the red underlines for @semanticNonNull are still expected at this stage.
I would still expect @nonnull to be detected though(see https://github.com/JetBrains/js-graphql-intellij-plugin/blob/21d5800921d07176992e3d006728a89a1c1eb242/resources/definitions/ApolloKotlin.graphql#L23)

@nonnull works just fine when editing graphql file, there is support for that. It just fails when executing graphql queries from IDE

Thanks. They work just fine from the app. Been using it for some time now on prod. It's just very convenient sometimes to verify something right from the IDE.

I created https://github.com/apollographql/apollo-kotlin/issues/5507 as a follow up before I forget.


Chore/146623139/add travisci badge to readme

What does this PR do?
Travis CI is an interface for vetting build structures. It determines if a build passes or fails. It comes with a badge to indicate the type of build.
Description of Task to be completed?

Setup a .travis.yml file in the root directory.
config the travis file and include all the settings.
Add travis badge to readme file

Any background context you want to provide?
Travis integration is kind of integration known as continuous integration.
What are the relevant pivotal tracker stories?
Integrate Travis CI badge and attach badge to readme

Please ensure the title of your PR follows the naming conventions.
You also have three commits that are supposed to be doing the same thing. Can you squash these please.

Please ensure the title of your PR follows the naming conventions.
You also have three commits that are supposed to be doing the same thing. Can you squash these please.


⚠ Processors has degraded performance

In 906a42c, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 41 ms

Resolved: Processors performance has improved in c3ff460.


Consider custom cookie class instead of servlet cookie

This would allow people to easily set samesite (and potentially other things).
The implementation would still just set a servlet cookie directly.

+1

@GitRowin @dkindler https://github.com/tipsy/javalin/pull/1353


What is the meaning of separateExpression and isSeparable?

The semantic of the separateExpression method on KEBinaryExpression is not really clear.
Tests should give the semantic more clearly and the method should be renamed appropriately.
testSeparateABinaryExpression

	| s1 s2 s3 s4 |
	s1 := 's=-(A+B+C)*E*D' parseAsAnEquation.
	s2 := 's=-(A+B)*(-C)' parseAsAnEquation.
	s3 := 's=(-E)*D*F*(A+B)' parseAsAnEquation.
	s4 := 's=(A+B)*(C+D)' parseAsAnEquation.
	self assert: 3 equals: s1 expression separateExpression size.
	self assert: 2 equals: s2 expression separateExpression size.
	self assert: 2 equals: s3 expression separateExpression size.
	self assert: 4 equals: s4 expression separateExpression size

The same for the method isSeparable.

separateExpression is used only in generateEvents method on KEExpression.
After a while, I was able to understand that separateExpression is about being able to express an expression as a sum of factor (the reverse of the factorization).

the form of the test is not appropriate. One should be able to express 2 different things in tests
a) expr 1 = expr 2
b) f(expr1) == expr 2 where == means identical in form

I refactor the test as:
testSeparateABinaryExpression

	| e1 e2 e3 e4 |
	e1 := '-(A+B+C)*E*D' parseAsAnExpression.
	e2 := '-(A+B)*(-C)' parseAsAnExpression.
	e3 := '(-E)*D*F*(A+B)' parseAsAnExpression.
	e4 := '(A+B)*(C+D)' parseAsAnExpression.
	self assert: e1 separateExpression size equals: 3.
	self assert: e2 separateExpression size equals: 2.
	self assert: e3 separateExpression size equals: 2.
	self assert: e4 separateExpression size equals: 4

More refactorings are needed in order to remove the use of Strings.


Updated process returns to list of lephare.onesource objects

This is a change to the lephare code and should be merged after the PyPI has been updated.
Closes #57
I will request a review when PyPI is updated and the tests start breaking
Code Quality

[ ] My code follows the code style of this project
[ ] I have written unit tests or justified all instances of #pragma: no cover; in the case of a bugfix, a new test that breaks as a result of the bug has been added
[ ] My code contains relevant comments and necessary documentation for future maintainers; the change is reflected in applicable demos/tutorials (with output cleared!) and added/updated docstrings use the NumPy docstring format
[ ] Any breaking changes, described above, are accompanied by backwards compatibility and deprecation warnings

The tests should start passing when PyPI is updated


fix(fw,tests): Fixes to EOF

🗒 Description
EOF classes use pydantic
EOF classes Section and Container now use pydantic BaseModel.
Opcodes with data portion are now subscriptable
Opcodes that have a data portion are now subscriptable:

Op.PUSH1[1]
Op.RJUMP[1]
Op.RJUMPI[1](Op.ORIGIN)

Where the subscript is used to define the data portion of the opcode, and the call arguments can now be used exclusively for the stack.
Data portion can still be passed as the first argument to the call, so Op.PUSH1(1) == Op.PUSH1[1]  == b"\x60\x01" but Op.PUSH1[1](1) will fail (we can begin to look forward to deprecate setting the data portion from the call arguments).
This is specially useful for Op.RJUMPV, where we can define each jump destination as a parameter of the subscript:

Op.RJUMPV[5, 6, 7](Op.ORIGIN)

In this example, the RJUMPV is converted into bytecode with three possible jump destinations, +5, +6, or +7, and the max_index operand is automatically set to uint8(3), and Op.ORIGIN is executed to set the only required stack element.
Fixes to EOF tests
All tests usages of RJUMP, RJUMPI, RJUMPV and CALLF have been fixed to properly use subscripts.
Notes
Fixed ~Tox is still failing due to file tests/prague/eip3540_eof_v1/test_execution_function.py~
🔗 Related Issues

✅ Checklist

[x] All: Set appropriate labels for the changes.
[x] All: Considered squashing commits to improve commit history.
[x] All: Added an entry to CHANGELOG.md.
[ ] All: Considered updating the online docs in the ./docs/ directory.
[x] Tests: All converted JSON/YML tests from ethereum/tests have been added to converted-ethereum-tests.txt.
[x] Tests: Included the type and version of evm t8n tool used to locally execute test cases:  e.g., ref with commit hash or geth 1.13.1-stable-3f40e65.
[ ] Tests: Ran mkdocs serve locally and verified the auto-generated docs for new tests in the Test Case Reference are correctly formatted.

tox -e tests-develop is failing as initial Prague support was added to t8n in
https://github.com/ethereum/go-ethereum/commit/823719b9e1b72174cd8245ae9e6f6f7d7072a8d6, full support should be enabled with https://github.com/ethereum/go-ethereum/pull/29557

validity_error=EOFException.DEFAULT_EXCEPTION,
logically this field does not belong to container. the container itself should be agnostic about its validity.
the validity lives on higher level

because I want to write custom_terminator=0x01 or 0x00
but that does not work as it must be bytes.

The reason we use bytes here is because you might want to add many zeros at the end for testing purposes and if you make this an integer you cannot specify more than one byte (0x0000 just resolves to 0 in python and the leading zeros are discarded). Maybe the correct name for this field should then be custom_terminator_bytes.

then all the reset must be bytes too for consistancy.
its a pity 0x0001  is treated as integer in python


[osal] Add initial OS Abstraction Layer API and posix implementation. …

Adds generalized Operating System Abstraction Layer (OSAL) API

task
mutex
semaphore
(message) queue
timer
ring buffer

Adds Linux (pure posix) OSAL implementation with unit tests
Adds Darwin (posix + dispatch) OSAL implementation with unit tests
Adds FreeRTOS OSAL implementation with unit tests

This layer is provided as an initial set of PRs to help solve #547.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Public repo requires all PRs to be recreated.


Detectnet-Caffe, python inference. Example.py detects incorrectly.

Hi I am trying to make object detection from python and using example.py (#1404 ).
It appears working and tells me the duration of inference etc, but the problem is; same snapshot is able to detect more objects in Digits web interface but example.py detects much less. Also, all the coordinates provided by example.py is empty, no objects there (I am assuming topleft corner is 0, 0 origin point).
I also tried inference.py but it was complaining about line 18....
Is there a reliable way to apply detectnet inference from python and get object count and coordinates?

Ok problem spotted in customized example.py, it is resizing the image, I think we need kind of --no-resize  option here.


Feature: Optimize XML in SettingsFileGenerator.xml

The SpreadsheetML XML in SettingsFileGenerator.xml is more bloated than necessary.  Clean it up and shrink the file size significantly.
This work item was migrated from CodePlex
CodePlex work item ID: '10571'
Assigned to: 'tfabraham'
Vote count: '1'

[UnknownUser@3/28/2014]
Resolved with changeset 74782: Optimize XML in SettingsFileGenerator.xml (#10571)


Twitter integration

Idea from February high-level meeting
Feature Request
Desired behaviour
As users add tools or workflows, we should trigger tweets on the Dockstore account. This can be done using the twitter api.

Superseded by specification about events I think


Export CSV with raw numbers.

Right now the exporting of the transactions use the preset number format.
Is it possible to  export the csv as a raw number format without the space/comma/period string-character.
The aesthetics of the number format are great and to my liking. but when i want to start fooling around with spreadsheets. it's just an extra step to remove the noise. :-)

Hi @jodeknudt, thanks for your message. We will consider your suggestion and come back shortly with the decision.

Hi @jodeknudt. We agreed your suggestion is valuable so we plan to implement it in the future.

Thank you for the feedback, looking forward towards to this little tadpole of a change.

Thank you for your report. Closing the card as the feature was implemented and would be included into the upcoming release.


No indication whether mint has been successful or not

Hey guys!
I am following your tutorial on youtube but I think there should be an indication whether the mint was successful or not, even a loading spinner would be good addition. Is this a bug or this has not been implemented at all?
Thank you!
Cheers

Duplicate of #11.

This would be awesome to see in the dapp. A simple Success textbox would do the work. Curious if someone has already implemented by their own.


Always use lower case URLs

Is it just me or does CamelCase URLs also hurt your eyes? 😬

Solution
Change catalog URLs like:
http://localhost:3000/catalog/Component/searcher
to
http://localhost:3000/catalog/component/searcher

This currently needs a tweak to the catalog backend to work out, since its API is case sensitive.

This is related to #1947 , that wants to uniformly make kinds case insensitive in general.

I believe this has now been fixed. On my instance all URLs are lower, and if I try uppercase for the kind, it rewrites it lower, so I'm thinking work spun out of the linked RFC was done.  Thinking this good to close - @freben / @Rugvip ?

I believe this has now been fixed. On my instance all URLs are lower, and if I try uppercase for the kind, it rewrites it lower, so I'm thinking work spun out of the linked RFC was done.  Thinking this good to close - @freben / @Rugvip ?

The URLs in TechDocs are still case-sensitive with kind :/
https://demo.backstage.io/docs/default/Component/backstage

The URLs in TechDocs are still case-sensitive with kind :/
https://demo.backstage.io/docs/default/Component/backstage


[Baselines Performance] Observations batching cache

Motivation and Context
We currently batch cpu-side tensors by doing cpu-stack -> cuda, however, that cpu -> cuda transfer implicitly results in a copy to pinned host memory (cuda can only copy from pinned host memory).  This PR maintains a pool of correctly sized pinned memory buffers so that we can implicitly stack by copying into the correct buffers and then do the transfer.  This skips a cpu -> pinned host memory copy.
For the standard 256x256 sensor, this doesn't really matter, for a 512x512 sensor, this results in a 20 FPS (or around 10%) improvement for PointNav training and I expect that will go up as the number of large sensors increases.
How Has This Been Tested
Tests pass.
Types of changes

New feature (non-breaking change which adds functionality)

Yes! I was also just about to do this. The only minor issue this might cause is the sharedmemory VectorEnv batching we were discussing @erikwijmans , but we can work around this when we get to it and hopefully we can manage have the shared memory write directly to the pinned memory.

This will also really matter is the multi-sensor case like for pseudo-cubemaps and panorama sensors. 👍

have the shared memory write directly to the pinned memory

Unfortunately shared pinned memory is not a thing (as far as I know).
In the case of shared memory VecEnv, we'd likely not call this function, so all would be fine.

Sounds good. Let's get this merged.


[SPARK-7326] [STREAMING] Performing window() on a WindowedDStream doesn't work all the time

@tdas
The problem most likely resides in DStream.slice() implementation, as shown below.
def slice(fromTime: Time, toTime: Time): Seq[RDD[T]] = {
if (!isInitialized) {
throw new SparkException(this + " has not been initialized")
}
if (!(fromTime - zeroTime).isMultipleOf(slideDuration)) {
logWarning("fromTime (" + fromTime + ") is not a multiple of slideDuration ("
+ slideDuration + ")")
}
if (!(toTime - zeroTime).isMultipleOf(slideDuration)) {
logWarning("toTime (" + fromTime + ") is not a multiple of slideDuration ("
+ slideDuration + ")")
}
val alignedToTime = toTime.floor(slideDuration, zeroTime)
val alignedFromTime = fromTime.floor(slideDuration, zeroTime)
logInfo("Slicing from " + fromTime + " to " + toTime +
  " (aligned to " + alignedFromTime + " and " + alignedToTime + ")")

alignedFromTime.to(alignedToTime, slideDuration).flatMap(time => {
  if (time >= zeroTime) getOrCompute(time) else None
})

}
Here after performing floor() on both fromTime and toTime, the result (alignedFromTime - zeroTime) and (alignedToTime - zeroTime) may no longer be multiple of the slidingDuration, thus making isTimeValid() check failed for all the remaining computation.
The fix is to add a new floor() function in Time.scala to respect the zeroTime while performing the floor :
def floor(that: Duration, zeroTime: Time): Time = {
val t = that.milliseconds
new Time(((this.millis - zeroTime.milliseconds) / t) * t + zeroTime.milliseconds)
}
And then change the DStream.slice to call this new floor function by passing in its zeroTime.
val alignedToTime = toTime.floor(slideDuration, zeroTime)
val alignedFromTime = fromTime.floor(slideDuration, zeroTime)

This way the alignedToTime and alignedFromTime are really aligned in respect to zeroTime whose value is not really a 0.

Can one of the admins verify this patch?

The intent of the code does seem to be that the difference from zeroTime is what is supposed to be a multiple of slideDuration. From my understanding I agree with your change. Let's see what the tests say.

ok to test

Merged build triggered.

Merged build started.

Test build #31691 has started for   PR 5871 at commit 2611745.

Test build #31691 has finished for   PR 5871 at commit 2611745.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

You will not directly call slice(). When slice() is called internally, e.g. in WindowedDStream.compute(), the Interval given as parameter to slice is valid.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/31691/
Test PASSed.

Merged build triggered.

Merged build started.

Test build #31715 has started for   PR 5871 at commit 6ade399.

@viirya , you are right. I've changed a little bit to only perform floor when the fromTime and toTime are not aligned relative to zeroTime.
Also fixed a typo in the log message.

Test build #31715 has finished for   PR 5871 at commit 6ade399.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/31715/
Test PASSed.

Merged build finished. Test PASSed.

Merged build triggered.

Merged build started.

Test build #31730 has started for   PR 5871 at commit 48b4dc0.

Test build #31730 has finished for   PR 5871 at commit 48b4dc0.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/31730/
Test PASSed.

A little test would be great, yeah. Would still love a quick look from @tdas to make sure we're not missing something.

Merged build triggered.

Merged build started.

Test build #32230 has started for   PR 5871 at commit 82a4d8c.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32230/
Test FAILed.

i'll retrigger this job once i restart jenkins

jenkins, test this please

Merged build triggered.

Merged build started.

Test build #32237 has started for   PR 5871 at commit 82a4d8c.

Test build #32237 has finished for   PR 5871 at commit 82a4d8c.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/32237/
Test PASSed.

Hi, @tdas , will you be able to take a look at this PR? My team in Autodesk is trying to adopt Spark Streaming to do some real-time analytics for our services' API logs to serve various purposes, among which is to monitor our services' health in real-time based on API log statistics. Then we run into this situation where we need to perform reduceByKeyAndWindow on an already windowed DStream.
What I'd like to achieve is to do multiple-level reduce on the source of API logging stream. For example - let's say the source logging stream is at interval 1 second. The first level aggregation would be every 1 minute, which is the 60 intervals of the source stream. The second level would be every 1 hour. The third level would be 1 day. And we can do more levels if we want.
What I hope is that at each level we'll do reduceByKeyAndWindow so that its aggregation can be done over its immediate previous level, instead of always aggregating over the source stream. Level 3's reduceByKey will be based on level 2's result, level 2 is based one level 1 and level 1 is based on the source stream.
I would think this approach will be more efficient than always reducing over the source stream, particularly for the higher level (like daily and weekly) aggregation.

I'm proceeding with this since everywhere in the code it appears that the intent is for RDDs to start an end on a multiple of the slide duration after zero time. Therefore it seems like the intent must have been to take into account zeroTime.

Aah, this has already been merged before I got to it. That's okay, barring a few nits, it was good. Thanks @wesleymiao @srowen


input size 416 -> 832 makes nano  not converging on COCO and custom dataset

Hi, thanks for your excellent work!
input size = 416 works well on the custom dataset, but when changing to 832, the nano did not converge in 300 epochs (AP is always 0, loss keeps 10 - 11)
Here is the exp file
nano.py.zip
BTW, I try on COCO when changing input size from 416 -> 832, the nano also did not converge (loss keeps 5 - 6). This might be a bug.
Both use the pre-trained model you provided.

@liuruijin17 Did you use cache? When you change the image size, you need to delete the existing cache and re-generate it.

Ops, it's my mistake, I delete and re-generate it, then everything goes fine. Thanks a lot!


Event metric error

Detailed description
Event related metrics are computed from SQL queries made directly through the run_sql api, however, those queries keep failing because the name of the database and its kind is incorrect:
{
  "detail": {
    "http_info": {
      "content_encoding": null,
      "http_version": "HTTP/1.1",
      "ip": "<IP_ADDRESS>",
      "method": "POST",
      "status": 400,
      "url": "/v2/query"
    },
    "operation": {
      "error": {
        "code": "postgres-error",
        "error": "query execution failed",
        "internal": {
          "arguments": [],
          "error": {
            "description": null,
            "exec_status": "FatalError",
            "hint": null,
            "message": "relation \"hdb_catalog.event_log\" does not exist",
            "status_code": "42P01"
          },
          "prepared": false,
          "statement": "SELECT COUNT(*), trigger_name FROM hdb_catalog.event_log WHERE delivered = true OR error = true GROUP BY trigger_name;"
        },
        "path": "$[0]"
      },
      "query": {
        "args": [
          {
            "args": {
              "cascade": false,
              "read_only": true,
              "sql": "SELECT COUNT(*), trigger_name FROM hdb_catalog.event_log WHERE delivered = true OR error = true GROUP BY trigger_name;"
            },
            "type": "run_sql"
          },
          {
            "args": {
              "cascade": false,
              "read_only": true,
              "sql": "SELECT COUNT(*), trigger_name FROM hdb_catalog.event_log WHERE delivered = false AND error = false AND archived = false GROUP BY trigger_name;"
            },
            "type": "run_sql"
          },
          {
            "args": {
              "cascade": false,
              "read_only": true,
              "sql": "SELECT COUNT(*), trigger_name FROM hdb_catalog.event_log WHERE error = true GROUP BY trigger_name;"
            },
            "type": "run_sql"
          },
          {
            "args": {
              "cascade": false,
              "read_only": true,
              "sql": "SELECT COUNT(*), trigger_name FROM hdb_catalog.event_log WHERE error = false AND delivered = true GROUP BY trigger_name;"
            },
            "type": "run_sql"
          }
        ],
        "type": "bulk"
      },
      "request_id": "15a894c9-b80c-4c43-8a65-6c94acf85d16",
      "request_mode": "error",
      "response_size": 402,
      "uncompressed_response_size": 402,
      "user_vars": {
        "x-hasura-role": "admin"
      }
    },
    "request_id": "15a894c9-b80c-4c43-8a65-6c94acf85d16"
  },
  "level": "error",
  "timestamp": "2022-11-29T11:48:49.816+0000",
  "type": "http-log"
}

Suggested solution
Use the information obtained in the metadata endpoint to retrieve the list of databases. From the metadata response, filter those elegible for event processing. With the filtered list of databases, build a batch run_sql query to get the information. In the prometheus metrics, label each time serie with the database name the data came from.

That's a very nice idea @fpiriz-inditex, I'll look into it, but I'm currently quite busy with my day job. So it might take a while till I get to it. Thanks for the input! :)

Thank you! I'm working on it myself, but as Rust newborn, I'm not quite sure with the solution I came up with. I'll create a PR so you can review it and add comments.


Display the git version when startup

Right now, we have the following message on the console when startup:
00:19:26.615 [                   refine] Starting OpenRefine 2.7 [TRUNK]... (22ms)
Instead of TRUNK, need a git version to precisely identify a version.

Push this task. it should be done with part of the build system migration(gradle or maven)

@wetneb Can you add/squeeze this into 3.1 ?

Sure, good idea!


chore(controllers) handle new GWAPI type

What this PR does / why we need it:
Update GWAPI to 0.8.0 and fix compatibility issues.
Which issue this PR fixes:
Fix #4560
Special notes for your reviewer:
Copied comments from earlier draft:

The conformance test failure related to the AttachedRoutes is tracked in #4546

The conformance test failure related to the TLSRoute invalid ReferenceGrant is tracked in #4562. We can disable such a test as it has been introduced recently and we are not conformant yet with TLSRoutes.

PR Readiness Checklist:
Complete these before marking the PR as ready to review:

[ ] ~the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR~ no user-facing changes for new version compatibility.

Would be nice to have the version we update to mentioned in the PR title (which then subsequently lands in the git history) so that we get proper accounting what specific "handling new type" happened here


disease logs

These don't appear in the logs, but I think they should as they don't appear on the gene pages
pombase_disease_associations_mondo_ids.txt:SPBC17A3.01c    tim50    MONDO:0016021        PMID:30190335    2019-05-18
pombase_disease_associations_mondo_ids.txt:SPAC22G7.06c    ura1    MONDO:0016021        PB_REF:0000003    2020-05-12

MONDO:0016021is obsolete:
[Term]
id: MONDO:0016021
name: obsolete early infantile epileptic encephalopathy
comment: This term will be renamed to 'developmental epileptic encephalopathy' in OMIM.
property_value: seeAlso https://github.com/monarch-initiative/mondo/issues/2027 xsd:string
is_obsolete: true
replaced_by: MONDO:0100062


Monorepo

Fixes: #2, #4, #12, #17, #18

Closes #2
Closes #4
Closes #12
Closes #17
Closes #18
Closes #22


Check StanfordCoreNLP version

Very nice @kwalcock ! I didn't know you could do this in Scala.
Ready to merge?


Design the pseudo-random field elements generator using RPO

During recursive verification, we need to use RPO as a random oracle in order to render the interactive protocol non-interactive. In Winterfell, this is achieved using the Random_Coin<BaseField, RPO> struct in order to get a random oracle, call it public_coin. The Random_Coin struct has two fields; Seed and Counter:

Seed is used for reseeding via public_coin.reseed(digest) (or public_coin.reseed_with_int(integer)) which basically sets public_coin's seed to a new value computed as RPO::merge(public_coin.seed, digest) (or RPO::merge_with_int(public_coin.seed, integer)). After reseeding, the internal counter is set to zero.
Counter is incremented when public_coin.next() is used to draw the next random word as RPO::merge_with_int(public_coin.seed, public_coin.counter).

This issue aims at investigating the changes, if any, needed in Winterfell in order to render the Random_Coin struct friendlier for recursive verification. More precisely, the following questions need to be investigated:

The public inputs are used to initialize the seed for public_coin. This is done by writing the public inputs into a Vec<u8> and then hashing the latter in order to get an initial seed. Do the padding rules for RPO allow us to avoid passing by Vec<u8> and hash instead field elements directly? It seems to be the case but we should double check.
Is the current implementation of reseed_with_int optimal with regards to RPO?
For drawing many field elements it seems rather wasteful, in the context of RPO, to have to run one permutation per 1 random field element drawn. Should we change this?

Yes, I think all 3 of these could be improved in Winterfell and it would make the assembly code both more performant and simpler.

In Triton, we have one global (resetable) Sponge state. When recursively verifying, we use it for the Fiat-Shamir transform[^1]. Seeding is implicitly done through absorption. Multiple pseudo-random field elements can easily be generated by squeezing multiple times, without the need to keep track of any counters.
[^1]: among other things; After all challenges have been generated, we also use it for hashing of inputs with variable length.

Yes, I believe this is the way it is (was?) done in Halo2 and Kimchi as well.
The reason for the current way of doing things is related to the fact that Winterfell doesn't assume that the hash function is a sponge. I am also not sure how many changes are needed to support this in Winterfell.

Apologies for rambling about an approach you are familiar with; I don't know the constraints imposed by Winterfell and that those might disqualify said approach. :relieved:

I actually think it might be a good idea to refactor RandomCoin struct in Winterfell to be a trait which could be provided for specific instances of prover/verifier. This would help with this issue but also probably with #753.

Yes, makes sense! This way we can make use of the sponge structure of RPO as @jan-ferdinand suggested above.

Created an issue here https://github.com/facebook/winterfell/issues/162

Closed by #891


Alias to node_module not working

Describe the bug
We import icons in our Vue components from an npm package called vue-material-design-icons by using an alias of icons. We had this working previously with webpack and I'm trying to replicate the setup in Vite.
My ~ alias appears to be working fine but my icons alias isn't.
This is my configuration:
import { defineConfig } from 'vite';
import { dynamicImport } from 'vite-plugin-dynamic-import';
import vue from '@vitejs/plugin-vue';
const path = require('path');

export default defineConfig({
  resolve: {
    alias: {
      '~' : path.resolve(__dirname, './src'),
      'icons': path.resolve(__dirname, './node_modules/vue-material-design-icons')
    }
  },
  plugins: [vue(), dynamicImport()]
});

Which results in this error:

Is node_modules on some kind of exclusion list for aliases?
Reproduction
See description.
System Info
System:
    OS: macOS 11.5.2
    CPU: (8) x64 Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz
    Memory: 292.61 MB / 16.00 GB
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 14.16.0 - ~/.nvm/versions/node/v14.16.0/bin/node
    Yarn: 1.15.2 - /usr/local/bin/yarn
    npm: 8.1.3 - ~/.nvm/versions/node/v14.16.0/bin/npm
  Browsers:
    Chrome: 95.0.4638.69
    Firefox: 88.0.1
    Safari: 14.1.2
  npmPackages:
    @vitejs/plugin-vue: ^1.9.4 => 1.9.4
    vite: ^2.6.14 => 2.6.14

Used Package Manager
npm
Logs
No response
Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/vue-next instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

Looking at the screenshot you provided, the request is sent to /node-modules/vue-material-design-icons/ instead of to /icons/, so the alias is resolved correctly.
However the package doesn't include a file called Close. Either add the .vue file extension or add the extension to resolve.extensions[] (not recommended)

The missing .vue extension is the issue. We haven't needed to define them previously so never occurred to me as an issue. Thanks!


add some speed information below the interractive map

What if we just slightly reformat to make it match the legend of the static tier map above? I.e.:

 Tier 5: Download and upload speeds greater than 100MB/s.

Tier 4: Download speed between 50Mb/s and 100Mb/s, upload speed between 10Mb/s and 100Mb/s.

Tier 3: Download speed between 25 Mb/s and 50 Mb/s, upload speed between 3 Mb/s and 10 Mb/s.

Tier 2: Download speed between 10Mb/s to 25Mb/s, upload speed between 1 Mb/s and 3 Mb/s.

Tier 1: Download speed below 10Mb/s, speed below 1 Mb/s.

We should also add a space between the number and "Mb/s" where it's missing.

Tier 0 won't be shown (at least, not now)
This might look nicer/more concise (don't use bootstrap formatting)....
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ul
For example...
https://github.com/ds5010/broadband/blob/pb/docs/index.html


Strategy for error handling

This is tricky because of how we're steaming the input down... How to handle it if an error happens when we're in the middle of streaming down the json result?

Handled.


can't select items listed in autocomplete list while the view is inside UIStackView

Hi.
I'm developing an app using swift 2 and some where in my project I need to use your KSTokenView.
TokenView works great when it is not inside a UIStackView. as soon as I put it inside UIStackView (for resizing the app on rotation or bigger screens)  I can't select any items listed in the box in bottom of it. why is that?

It should work. Please example project "StackViewExample". You may debug the view hierarchy, to confirm if there isn't any view on top of it.

here's my test project. I've put the KSTokenView inside stackView without any extra views on the screen. it stops working correctly after I did that. take a look.
TestProject.zip

Try to use latest code from branch develop/swift2.3


Revamp nomination pool reward scheme

The old scheme had some elementary flaw, which is fixed here.
The main flaw with the previous one was that it was unfair to the reward of those who were already in the pool. In other words, If you join a pool now, any unclaimed rewards belonging to others would now also be shared with you as well. New tests ensure this property.
The new design is still scalable, in fact much simpler, and maintains this property as well. The spec is being written with proofs here: https://hackmd.io/PFGn6wI5TbCmBYoEA_f2Uw
The code should be a 100% clear mirror of what the spec is defining.
All existing pools on Kusama and Westend need to be migrated to this system. Moreover, a new fie field has also been added to members, which means all members also need to be migrated.

[x] write and battle test the migration.
Polkadot companion: https://github.com/paritytech/polkadot/pull/5757

/benchmark runtime pallet pallet_nomination_pools

Example output of migration testing:
2022-07-06 12:07:20.447  INFO                 main kusama_runtime: try-runtime::on_runtime_upgrade kusama.
2022-07-06 12:07:20.447  INFO                 main runtime::nomination-pools: [13440793] 🏊♂ Running migration with current storage version StorageVersion(2) / onchain StorageVersion(1)
2022-07-06 12:07:20.448 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 30ed0348562c1ed74187bf91ab00d4f734ce2505a6d6f5d189ca1f8dc966e665 (DgUDw179...) has 95.9183673%<PHONE_NUMBER>06) of pool 30 with total reward of<PHONE_NUMBER>86
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 2aa53f55efa82a9820f3c2569d4e52dc467475a1a11cfc9861ce5440316edb7a (DYEcn7dP...) has 4.0816326%<PHONE_NUMBER>) of pool 30 with total reward of<PHONE_NUMBER>86
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 137 leftover to the depositor: Ok(())
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ acaa7863652fd2a4e1e414e49596960e015ba7b21e1ade307efdde668fe80149 (GUiPpM5w...) has 83.3333333%<PHONE_NUMBER>6) of pool 54 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂<PHONE_NUMBER>4a1b98d0f7e959eaa4807138370af1fdd890325e73fa5b38f09537 (FyM3yUuu...) has 16.6666666%<PHONE_NUMBER>) of pool 54 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5a42cfe1a2323360f3e70cfc35891e76313a94cc71e14f5182dbe715e28fae13 (Ecfg63TS...) has 0% (0) of pool 54 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 22 leftover to the depositor: Ok(())
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4696cb35a57b9e515c0fee6693802cd2202996a1d83000d2c339e6a0df441632 (EAsfWjF2...) has 100% (0) of pool 40 with total reward of 0
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 98ed7a64115d8298bdc0722bfe79ed744cdd5229153e90c8f73a8364bebe206e (G2qLnhid...) has 15.1260504%<PHONE_NUMBER>) of pool 48 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 8038340e8db4310b3c236b9115bba5823288dd718e18870ec6f00780722e9957 (FUSLqoLQ...) has 42.0168067%<PHONE_NUMBER>) of pool 48 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ dac2b2d601c08d3d0af9aba324635a77c127faead25304e970508be476de121b (HX9o1yVX...) has 13.4453781%<PHONE_NUMBER>) of pool 48 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 36f9ebebc56204293ab80f824a1a9c6de929eb29516ac93f9fe20a5f325a870e (DpQM1Rxw...) has 12.605042%<PHONE_NUMBER>) of pool 48 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 965c7661da304c393e7f185a61e003547cb59962b6c6fe8c2a4c7e28b8f70601 (FyUAfxdH...) has 16.8067226%<PHONE_NUMBER>) of pool 48 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 32 leftover to the depositor: Ok(())
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ fe249380a8af82ce278c024eafd729172eff018106e2baccf23e2688507e033b (JKYYceWY...) has 75%<PHONE_NUMBER>2) of pool 7 with total reward of<PHONE_NUMBER>43
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 620bf3238b87d89488c5b47a1e69a5e72ba1016ac24a71eac6258f49d3424502 (Ensm3vgH...) has 12.5%<PHONE_NUMBER>5) of pool 7 with total reward of<PHONE_NUMBER>43
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e46a6b5c2f3c09cab5b2970616ba2224cf6f333404eb61a7ca569988aefcbe3c (Hjp3mvzg...) has 12.5%<PHONE_NUMBER>5) of pool 7 with total reward of<PHONE_NUMBER>43
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 1 leftover to the depositor: Ok(())
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 2055808c210d863dfc372ec85beafa8fd3a8ff497f8eaee401ef05bf27d3065b (DJiT2Vbs...) has 30.2114803%<PHONE_NUMBER>54) of pool 35 with total reward of<PHONE_NUMBER>40
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 8a572acd6c7fcbab7c951bde7bcb67a7bc8d237b106b508747ffa8394223951c (Fhi27LMn...) has 0.3021148%<PHONE_NUMBER>) of pool 35 with total reward of<PHONE_NUMBER>40
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ bea06e6ad606b2a80822a72aaae84a9a80bec27f1beef1880ad4970b72227601 (GtGGqmjQ...) has 3.021148%<PHONE_NUMBER>9) of pool 35 with total reward of<PHONE_NUMBER>40
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 284eb76f4116f4b75a718fd1a374cc5b6e02fc18f37e02deb3054e57539c5328 (DVApLCwM...) has 3.021148%<PHONE_NUMBER>9) of pool 35 with total reward of<PHONE_NUMBER>40
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 362f9efe78a0d238501313e68a74a9b6257f406c5c62c9162d96852a13f79902 (DoNFTAF8...) has 60.4229607%<PHONE_NUMBER>61) of pool 35 with total reward of<PHONE_NUMBER>40
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 8c9138d2fa37cdda19528964efe98c0df5ca0bf5e6527af1a25d49b6057ed03c (FkdMvcEe...) has 3.021148%<PHONE_NUMBER>9) of pool 35 with total reward of<PHONE_NUMBER>40
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 908 leftover to the depositor: Ok(())
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ f4d95d4c5c0131969148d3a16b3d95ab3d051771d971a1955d7e745b0a3a4f16 (J7MmkYX4...) has 90.9090909%<PHONE_NUMBER>5) of pool 37 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ccc49a4cbcaec6b03737d84c907628a2cc104cc75ad817ad38292e5bb76c527e (HCogweij...) has 9.090909%<PHONE_NUMBER>) of pool 37 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 17 leftover to the depositor: Ok(())
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ aa2b3e0a8702aebcb83d552838a17902b2403b0f16c4e52a4514fe02df532e3c (GRSWBC1k...) has 100% (0) of pool 20 with total reward of 0
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 900bb1ae4b236d7cb85258370cc62b4b947ca7adb6b0040f47f9c130f1946a40 (FqBtQGyu...) has 0.698812%<PHONE_NUMBER>) of pool 38 with total reward of<PHONE_NUMBER>59
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 6088bbc699f2b1695f114a339f1bc8755dd95e8751c8961e7a85a108e48f7166 (EktjUEd3...) has 30.0489168%<PHONE_NUMBER>1) of pool 38 with total reward of<PHONE_NUMBER>59
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 92c3fba822e553c4647a2e07c011c3be37a1126d7c5b65822d5271b82541e237 (FtkjBVfN...) has 6.9881201%<PHONE_NUMBER>8) of pool 38 with total reward of<PHONE_NUMBER>59
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c67606bcca55411186a3685015831830f276d1101ba0c47bd4d34cc67be5937f (H4Y4SRHk...) has 0.7686932%<PHONE_NUMBER>) of pool 38 with total reward of<PHONE_NUMBER>59
2022-07-06 12:07:20.449 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5c3739d60301126756a7510e34f9d656d4435cd4fe64bbd001f1f3473bc9c333 (EfEL21i1...) has 61.4954577%<PHONE_NUMBER>87) of pool 38 with total reward of<PHONE_NUMBER>59
2022-07-06 12:07:20.449  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 481 leftover to the depositor: Ok(())
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ aef5713b3583a5730c08c16d252f9fbda97536c8a26168256b998f7e9fc1c602 (GXim7LFQ...) has 100%<PHONE_NUMBER>8) of pool 13 with total reward of<PHONE_NUMBER>8
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 40de2e8a6b2796d5dec616ffdb7663a3b4ae6d33c32433dfa007200fd2de0a63 (E3NaqTcJ...) has 100%<PHONE_NUMBER>9) of pool 26 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 12c0e71d330bdafa9c3a6218dcea201399a6cfe0fa73c2692e7a83492614e40a (CzugcapR...) has 100% (0) of pool 57 with total reward of 0
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 1cbe59b1e375a52b9131fdb7a85c0992b8c5cdc3f4b4d90e19185972cef58b2a (DE1QQkVP...) has 100%<PHONE_NUMBER>2) of pool 5 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ b2636043fc3b8dfa608167a9fb6fb9d065b9f2f5821dc4bfc9785a244b24a92a (GcDZZCVP...) has 0% (0) of pool 5 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5c64e75ed0cc23a7549328bc0ca90ab7fe11581fce45b6f48d8d3b6967c0b31d (EfTu2fub...) has 100% (0) of pool 41 with total reward of 0
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5865da029ac7366bc43ae9d19382b3a85f49d2a660fef29259f9bdd742767d0c (EaDzFVuQ...) has 100%<PHONE_NUMBER>8) of pool 44 with total reward of<PHONE_NUMBER>8
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ d9c958ec068aaa78b0d6256fea94a50cd19bdc1f82f905e88b4bd0bb5626ecf0 (HVsio7zD...) has 33.1114863%<PHONE_NUMBER>052) of pool 52 with total reward of<PHONE_NUMBER>550
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ca5bc1915da74aba3aadd7ce7b809045d5eb5b73559259755fdcd85a40a5dc6e (H9eSvWe3...) has 0.6622297%<PHONE_NUMBER>0) of pool 52 with total reward of<PHONE_NUMBER>550
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ba19adf8ab8528c9f53058b494b6154dde0fadfe2bdeb3a9b9c87761cdcbb441 (GnL41mJJ...) has 66.2229727%<PHONE_NUMBER>337) of pool 52 with total reward of<PHONE_NUMBER>550
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 1e069328eb826785f0f58f3f42d0921da45c2c8f60230bc7a6d9f23e420f6524 (DFguaxZp...) has 0.0033111% (239521294) of pool 52 with total reward of<PHONE_NUMBER>550
2022-07-06 12:07:20.450  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 14467 leftover to the depositor: Ok(())
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 2a08df06231fddfa6be5cdb3fcf5d7ac0aadaa4d0c709f743c0e63667b095761 (DXSAUk6Z...) has 29.461822%<PHONE_NUMBER>9) of pool 8 with total reward of<PHONE_NUMBER>29
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4ea8dd0f74def3f37653a2bc9932edbaa87ba9a185c55cd8b5bd733ea86c6257 (EMTR4nXB...) has 70.5381778%<PHONE_NUMBER>83) of pool 8 with total reward of<PHONE_NUMBER>29
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e442aaad715153a1515d843b05b774fd7a3b52cfc011cd718975b44ad239d831 (HjcErRij...) has 0% (0) of pool 8 with total reward of<PHONE_NUMBER>29
2022-07-06 12:07:20.450  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 487 leftover to the depositor: Ok(())
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e06ae7e8f2d0a595785469e734545f7c01684542d910d3098d1d9e8fef321829 (Hea13nX8...) has 100%<PHONE_NUMBER>) of pool 55 with total reward of<PHONE_NUMBER>
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ a6915d6fb30cd30367f23194c68842a6018f565c773ea0c544eb2a62597b1b34 (GLiebiQp...) has 100% (0) of pool 33 with total reward of 0
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 64f52da91eb669940b066cc4a457320f52d5410debbf7d7b0c568521b946fa07 (Erh93LaM...) has 100% (0) of pool 39 with total reward of 0
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 84b1fb0b5be19e82f7160b19a050e21f6708c69105b348b26f6de75f94737062 (FaJi8E1W...) has 8.36405%<PHONE_NUMBER>98) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ fa66a1d03188f03e54c5cb25bcba28edeadbfb52217f0fd414ff64b82df8c463 (JEdyd5Vq...) has 19.5957743%<PHONE_NUMBER>599) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 0c613e1261949b5e9c2d1256c7562ce7a520710f61899ce48f1b48e37d290808 (CrYym7rg...) has 1.1948642%<PHONE_NUMBER>4) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 9abb4310245d08fe014afff85f24701bf5635ffa3446e6745ec3d8b4b7aefe38 (G5CX94JN...) has 0.1194864%<PHONE_NUMBER>) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ d83664164335d7f606083a2fff11de28eb8ff5527ed9ff92563fd601b19d4b64 (HTp224Tr...) has 14.3383714%<PHONE_NUMBER>08) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 44d50e5b2db8b483e5731d39c1e71f33d6ab32318c144f5dc41e57d1d21ee779 (E8a4iJyD...) has 0.2389728%<PHONE_NUMBER>3) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c6499e2c3759b9c03a136f81898f4b45000cfe6cbbd5c6d0c80322df1988674b (H4JsJJig...) has 0.0238972%<PHONE_NUMBER>) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4c5d312a664e02798f3312144a9dde3decb1d69377775dbcfebc3510f2205b67 (EJSqirfg...) has 0.0238972%<PHONE_NUMBER>) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 049f1705eece315a6be9db3c2c1a50744f3cf8a407ad66466bb883bd67573c40 (CgNy9etA...) has 0.0310664%<PHONE_NUMBER>) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e062699794e584f46640205631a5c6c459174d8ddafda594bfc4c00af73815d5 (HeXUiADx...) has 39.9064301%<PHONE_NUMBER>633) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 969420fed60d4e663f0b574f45b2def50eba51e70ee46efce6b89f0ffc0c6d7f (FykhnPA3...) has 0.0716917%<PHONE_NUMBER>) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5a2d13a5994df05d1158f5776bb8371a8808cd22c098344874b27484ecf16b2f (EcZDbbvy...) has 1.4099397%<PHONE_NUMBER>5) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.450 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 3335dcae122afec0485797d13ac268f80b7b9d2f798cb4f6d8f634866b61ce26 (DjTxebzp...) has 9.9021002%<PHONE_NUMBER>21) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 66b258b13221cfcb61ac4879b106f24b2375c1019de8d988c995913ab45eae77 (EtyP7GBH...) has 4.779457%<PHONE_NUMBER>56) of pool 1 with total reward of<PHONE_NUMBER>118
2022-07-06 12:07:20.451  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 91137 leftover to the depositor: Ok(())
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ f64689da7688eec693a364879994be8568da0f7ff5223c391b6b58626f827527 (J9EFZ5Qx...) has 100% (0) of pool 19 with total reward of 0
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 68d8d44ac64851dce09aaccb495984e1f649f9ffd62ebe4a1e0011a26ecae448 (Ewnuhwzh...) has 96.7741935%<PHONE_NUMBER>3) of pool 45 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ dec12419c7cea97a40260bd0484f4baab31a0f389af00420eac59fa0a63c644d (HcPXHpHL...) has 1.6129032%<PHONE_NUMBER>) of pool 45 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 2ef06012b7d32a87f6799d11036d26f7463ada3ba9810c6fbd6b738bca96b30f (Dds8JzxE...) has 1.6129032%<PHONE_NUMBER>) of pool 45 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.451  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 77 leftover to the depositor: Ok(())
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 0c4b0402052d12fdac3015795630050dc91615f514d733263012567e4018993b (CrSNoVb2...) has 16.1825726%<PHONE_NUMBER>28) of pool 9 with total reward of<PHONE_NUMBER>091
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ defcb659c365beee8365b3393d7b99933db97df1733000dacb4873efc4ea9950 (HchDgQG3...) has 83.8174273%<PHONE_NUMBER>221) of pool 9 with total reward of<PHONE_NUMBER>091
2022-07-06 12:07:20.451  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 1542 leftover to the depositor: Ok(())
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ faba4f34d61e2defae2db1f7c712007824c194ad921959efdb4a65dd174a590c (JF4qMDoQ...) has 100% (0) of pool 16 with total reward of 0
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 3a0b67c6e4b35133a18ff9c3b56d6cd28662f9e47f38afbfc508543087966870 (DtRgaYr6...) has 100%<PHONE_NUMBER>6) of pool 53 with total reward of<PHONE_NUMBER>6
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 1a35d1705ba167728d6778846631cfc86a1275d6409e184020aa2c6787d5aa61 (DAgkTcvQ...) has 0% (0) of pool 53 with total reward of<PHONE_NUMBER>6
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ aa02d12d3bba42d592a97793cf4d000f147fe8ceec7e59ecd08fa2a1f3290372 (GREVfZSg...) has 100%<PHONE_NUMBER>1) of pool 14 with total reward of<PHONE_NUMBER>1
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 8c2625b0e10c7bf65f283c576878cf00f67478d3dbb6bf39ee62b3ca19ce893d (Fk5Z52gA...) has 33.3333333%<PHONE_NUMBER>5) of pool 43 with total reward of<PHONE_NUMBER>5
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 066cbceb54526209a93b10caeff411533e9ec65074f6468708a4d409f579c168 (Cik7AFtf...) has 66.6666666%<PHONE_NUMBER>9) of pool 43 with total reward of<PHONE_NUMBER>5
2022-07-06 12:07:20.451  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 41 leftover to the depositor: Ok(())
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ f429460ae52548e754c712a7cfc75f1bf7c9295da165293ca52ccc686db5c02d (J6TTn21p...) has 100%<PHONE_NUMBER>2) of pool 31 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ae177e35d7f8a77f2e31cbf3dc4c0fbf3a33480b46104fc1dbbc088fc0e7f06d (GWaq1gXP...) has 100%<PHONE_NUMBER>2) of pool 21 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ f4492a28ead0b315fc68069bcc39470c409d12b4e48259384d63da411bad0129 (J6cwFK1b...) has 100% (0) of pool 15 with total reward of 0
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c6e8495172700261c13a3a05c52aac5dde3cc45f553fca796dc622efbaeb7c38 (H5816RvR...) has 33.3333333% (313492773) of pool 47 with total reward of 940478319
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 180e0bbab137521c05b4d905878159e631e8d58f8f98eb54bcde45355a64a42d (D7rqeKiv...) has 66.6666666% (626985545) of pool 47 with total reward of 940478319
2022-07-06 12:07:20.451  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 1 leftover to the depositor: Ok(())
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 6c03982e9d7c7134f266bf1d7fe8227fb4856b93bb8b439045cb9ef8a201c065 (F1wksBD1...) has 9.090909%<PHONE_NUMBER>) of pool 24 with total reward of<PHONE_NUMBER>0
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ dc7c8c782c6342f5f4733bedee4233277d3d1273efdcaed975969f4a7948180e (HZR3vCq7...) has 90.9090909%<PHONE_NUMBER>7) of pool 24 with total reward of<PHONE_NUMBER>0
2022-07-06 12:07:20.451  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 19 leftover to the depositor: Ok(())
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4211b834beac4f35ff92e0dcbb0167f6ae7a0c43b186727d581d3f69f10fea34 (E4wwb5tD...) has 100%<PHONE_NUMBER>85) of pool 49 with total reward of<PHONE_NUMBER>85
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ be29ae471fd4b81a6efb3dc6bc7fe4b65b52d646e24373b4237613322099e63e (GsezpN8s...) has 100%<PHONE_NUMBER>9) of pool 22 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.451 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e22baee6a790a63088620f7483290c83fcb3337664866cd8d239568f7554bb14 (HgsKJTfV...) has 100%<PHONE_NUMBER>4) of pool 51 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 36dafe22546294dab15b18d1f15fed8856e6ace31582b0dca7f8d450cd963368 (DpFA7i4o...) has 33.3333333%<PHONE_NUMBER>03) of pool 29 with total reward of<PHONE_NUMBER>238
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 6a5792ca44d6d45477975619addf83d50ab93b49f64af5a61d4a0a9ddd376d03 (EykcEZo2...) has 33.3333333%<PHONE_NUMBER>03) of pool 29 with total reward of<PHONE_NUMBER>238
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 6e47608ca20d1b92a1fd2faddb0f7006c9cf462c98fe0cf78333aff5400a8465 (F4uzHiVP...) has 22.2222222%<PHONE_NUMBER>68) of pool 29 with total reward of<PHONE_NUMBER>238
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4cba9937a660457871af3582bf25eceefc8f5dd9654ac8634a49c4d37713e46b (EJvb5VFk...) has 11.1111111%<PHONE_NUMBER>34) of pool 29 with total reward of<PHONE_NUMBER>238
2022-07-06 12:07:20.452  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 2130 leftover to the depositor: Ok(())
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4a09f333d4c9f701ad0a2a7c8bcafa9df046266151998d61d93023e035294144 (EFQ1wXD4...) has 1.466209%<PHONE_NUMBER>1) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 7412d6d88c09f9b85f8927d5824a48d29362f840a502d530d37c02015c10382f (FCWfkDNp...) has 0.7550976%<PHONE_NUMBER>5) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ae5beb9a0283915545d71d55ad57836ee96ea156055c9718b3e96d55037b5930 (GWw9zEkg...) has 1.4515469%<PHONE_NUMBER>6) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 96e24e9b5ab82dc275b82318a52cebed1cae3e25be096d5f288229b256359e43 (Fz9vm8qY...) has 75.1770806%<PHONE_NUMBER>379) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 58a7c12a2b3fa6655d4bbbc172ab4958104aebda8561f8015fb835b44b1870f5 (EaZZjRAU...) has 2.1993135%<PHONE_NUMBER>1) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ f0b0a33facdd449c33d173a8e4df987b0009aec548340ce385f26504149d990c (J1uUwH84...) has 0.7331045%<PHONE_NUMBER>0) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ bc40b85a7330b96f88bb98278f040b0714432729869d0df8bd9461434469921b (Gq9kDp4v...) has 0.9530358%<PHONE_NUMBER>8) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 02b762fa1350965bdbc67625a395ae3bae8390f0f7bcfdeee7041768115e5026 (Cdt6DaWq...) has 0.8577322%<PHONE_NUMBER>2) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 80d78d061fdbe7d3978dd8093121356d6ec7935c9fc40c8bd57b3cda5531852f (FVFgLT6V...) has 1.5468505%<PHONE_NUMBER>3) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ fc3293e3726ef502bc4a2ab1e99044bc53bc0dd56ae76912a93e2d714c96500f (JGzcJRJj...) has 1.0849946%<PHONE_NUMBER>4) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ d656ccf23d3b30f021bfbadb5527d17e939ded05072024b0cb5fa2846c1d1450 (HRMYsMWe...) has 0.0733104%<PHONE_NUMBER>) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4cd230455bd14439d924076c4c393be8f1244f6764a51a9457a7c935625b096d (EK3bXRTy...) has 1.0996567%<PHONE_NUMBER>8) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 623a83df18a4035e3f753cf28bd99cfee9d86937a0249e64c0edfaaf774aad70 (Eo7bMUJj...) has 10.9965679%<PHONE_NUMBER>16) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ced578d3b61f46d8dc621a95d4d40bea0f0071878faf50cc3f0c4ad6cdf40530 (HFWo9YHu...) has 1.6054988%<PHONE_NUMBER>6) of pool 2 with total reward of<PHONE_NUMBER>016
2022-07-06 12:07:20.452  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 14149 leftover to the depositor: Ok(())
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 9657f328efc94673d2057a7bf1aeb352ee7c81fe5abfa37c1e0601f82d5df946 (FySpvTQ6...) has 78.807947%<PHONE_NUMBER>0) of pool 10 with total reward of<PHONE_NUMBER>1
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ba0fd6f27641caae31c5173ac7391bd1ada4ab54d32dc6f55e9ea041be870964 (GnH8UYpP...) has 1.3245033% (244701555) of pool 10 with total reward of<PHONE_NUMBER>1
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c437a8a4bf75d3680ee2bb36c7e7f4ed7b938d1528e76412475a71fa2b7cd46a (H1bSKJxo...) has 19.8675496%<PHONE_NUMBER>) of pool 10 with total reward of<PHONE_NUMBER>1
2022-07-06 12:07:20.452  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 18 leftover to the depositor: Ok(())
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 663b801c02f2b76565f5b60d817e7dd805babdc276b53d20e19cebd199c88555 (EtN5SSSb...) has 100% (0) of pool 27 with total reward of 0
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e2af982fd853bcdb276d9be46e6bad4cc8e1af153d82638d2bc829e6ec3e2a6c (HhYW5bwU...) has 100%<PHONE_NUMBER>9) of pool 28 with total reward of<PHONE_NUMBER>9
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 042b4c7d7dc272ce8ed55558420c9fea6ccef4f30c3cc09ed55f4dc0a02fac32 (Cfna7dEe...) has 100%<PHONE_NUMBER>5) of pool 6 with total reward of<PHONE_NUMBER>5
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 06b430745802c7c8d5cb3537dde6dda1c74dd2251837c781be4e0aebfde8d673 (Cj7LEkGT...) has 100%<PHONE_NUMBER>) of pool 11 with total reward of<PHONE_NUMBER>
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c2de6256e9ff0ba9b97f862290f69ec0f72b31fa0a6843e0175e9e81a0165d6b (GypsNbin...) has 83.6499692%<PHONE_NUMBER>48) of pool 3 with total reward of<PHONE_NUMBER>08
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 8e440155dbcfc35f8ab14a59e107930a14d903c5e9c4d6efeb6ecdca71d0176e (FnrX4nNy...) has 12.1675322%<PHONE_NUMBER>0) of pool 3 with total reward of<PHONE_NUMBER>08
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ bae09878d7a9b24afaedfc8f7583489d17b8f8f960f2d568e23b235fde2c3526 (GoM9FsSX...) has 4.1824983%<PHONE_NUMBER>7) of pool 3 with total reward of<PHONE_NUMBER>08
2022-07-06 12:07:20.452  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 1453 leftover to the depositor: Ok(())
2022-07-06 12:07:20.452 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ a83fc2798fabbdc8d93db99a27dda9b8f6615cfef0b16a3a0aca93a49e527475 (GNvW8KgQ...) has 100% (0) of pool 17 with total reward of 0
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5eb083f19535ddfc1936497ce8db7b4dfb4af273000c4e2b9148077da9260547 (EiUTLnsK...) has 2.3084166% (433044116) of pool 18 with total reward of<PHONE_NUMBER>7
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ d81108d4878be65507d52a8e060ade2b54ce9f32871fa8c5fe34c80ce3eda464 (HTcvP7Wr...) has 4.1551501% (779479450) of pool 18 with total reward of<PHONE_NUMBER>7
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 04f3da939fa351c562c7e06e1e3716976b5e14230e83a45995cbad9086f49e17 (Cgp9bcq1...) has 93.536433%<PHONE_NUMBER>5) of pool 18 with total reward of<PHONE_NUMBER>7
2022-07-06 12:07:20.453  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 56 leftover to the depositor: Ok(())
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 120dbd220521490559af15d7fb3b6cd95c313d06180901d2de5a54e63d9cfe22 (CyzTh1ch...) has 100% (82671708) of pool 56 with total reward of 82671708
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 5270ec35ba01254d8bff046a1a58f16d3ae615c235efd6e99a35f233b2d9df2c (ESQzLXFR...) has 100%<PHONE_NUMBER>1) of pool 23 with total reward of<PHONE_NUMBER>1
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 1a88ff7253355a51329e1dc8c0265bd31557b136743a91332a36f7ec8316c66a (DB7TcWBF...) has 0% (0) of pool 4 with total reward of<PHONE_NUMBER>14
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 985072f9a9f181b468a8d4ceb71d0916990146876a151c45559339e7e464c84c (G22hF2a8...) has 4.6948356%<PHONE_NUMBER>) of pool 4 with total reward of<PHONE_NUMBER>14
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ d25af2fedd4eb672f218932fde44f97f10c1d7788efd0079957ffad4f186ae78 (HL8bEp8Y...) has 23.4741784%<PHONE_NUMBER>4) of pool 4 with total reward of<PHONE_NUMBER>14
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 86929ec01fdfdecf2c5ad0c4f9b537e65084f053980fa1215fb9377dc325f52d (FcmVMJEb...) has 66.6666666%<PHONE_NUMBER>5) of pool 4 with total reward of<PHONE_NUMBER>14
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 387cbbabecc63d610ae7d4e8089aa6b341a52764f822342e887ba35160a26a61 (DrPFcfMy...) has 0.4694835% (687336599) of pool 4 with total reward of<PHONE_NUMBER>14
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4c0d0e7f518ed46e1c0a29ca662ec6460147f855e463e40ef2a8966f5cee551f (EJ332BrJ...) has 4.6948356%<PHONE_NUMBER>) of pool 4 with total reward of<PHONE_NUMBER>14
2022-07-06 12:07:20.453  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 438 leftover to the depositor: Ok(())
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 9adc49ef3682eb4c032cd0e0088fdc1e5996bf28cfa889bd3c7dc32cecce2e15 (G5NLBLGA...) has 1.6815225%<PHONE_NUMBER>) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 4cd37fd36e084f1e64a7d73c2b570f90581c5010c6f67ef8284ccf56a3359c13 (EK3z7HhA...) has 9.8317853%<PHONE_NUMBER>2) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 0e038a8abb8af57e030d01ec5b23e31cb5732bc3d5c9a781d5b98bea6854fe11 (CthEt2Cn...) has 3.4027087%<PHONE_NUMBER>) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 2a3a79d6cb82c0f1fff14cbb78d3b7fa64b5a9a3fd9c54fd4e78a5cbfbade710 (DXgu9bae...) has 10.089136%<PHONE_NUMBER>0) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 1c312721adb7ed428f9860e94904a907406f00b5c8c567187ee6b4d1fd2c1508 (DDHTdiJm...) has 17.0491284%<PHONE_NUMBER>1) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ba489a03693e64b349071f764113a42091d5a043f7053c489818160a2e636a37 (GnZzTk4f...) has 34.0301285%<PHONE_NUMBER>2) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c0f202c8f507b65b955b26009abc5972b0058bacd9061d0ed2e01fa7b5c8ae41 (GwJbym6R...) has 16.0261734%<PHONE_NUMBER>9) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 1c566162ff0c0f637e2f105e5d77ec00b3112f391df64045e474af898cb96a4e (DDUX3qS8...) has 2.7634624%<PHONE_NUMBER>) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 2824387bf41c0f2b7e25adce8e897204e9c05cb97e57581111b448ed78bcc101 (DUxC9Lpp...) has 5.1259537%<PHONE_NUMBER>) of pool 34 with total reward of<PHONE_NUMBER>21
2022-07-06 12:07:20.453  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 1311 leftover to the depositor: Ok(())
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ f2395f3e80b47fe6ce9eaf63553371c59c73b403bdc28862c86ab1040e62226a (J3v9bJ22...) has 99.0099009%<PHONE_NUMBER>0) of pool 32 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 9a456a6b6ff5d2205b15dcefd1f4b87f1031062fa660f9a7285751e10fbbb468 (G4bWhKD4...) has 0.990099% (392206094) of pool 32 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.453  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 40 leftover to the depositor: Ok(())
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 600f84337fe8a23101c908bdcde6b2c4d32a25854efc0ed1937822e6200ed662 (EkGiwyFm...) has 96.7741935%<PHONE_NUMBER>9) of pool 25 with total reward of<PHONE_NUMBER>5
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 800aab741beaf15ba953897b937ea73ec9d823b1f882e375e6e0863e1537d840 (FUCpKJcq...) has 3.2258064%<PHONE_NUMBER>) of pool 25 with total reward of<PHONE_NUMBER>5
2022-07-06 12:07:20.453  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 82 leftover to the depositor: Ok(())
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 7c50145c707078b4d38802058b2d16fd80748729aac222af64be9e55e854da2a (FPKF7LYY...) has 100%<PHONE_NUMBER>8) of pool 12 with total reward of<PHONE_NUMBER>8
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c48166c755e708cb83a61db9dc635e91cb496e2659e07fde8aeb09130802010e (H1yLse54...) has 100%<PHONE_NUMBER>4) of pool 42 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ ea20b747bdcf750d1bccf49b540459ddf5c94584af7d404c16d2ac8126ff8520 (HsJSZMkr...) has 57.4468085%<PHONE_NUMBER>6) of pool 36 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.453 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 00c6fad38515e62f83f804861803773ae17af068898dec6d558c903663078754 (CbLdKvBg...) has 21.2765957%<PHONE_NUMBER>8) of pool 36 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.454 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 284e0442b44363d362b1194b107f46ec28e76932170fdbbf8077dbe87aa26001 (DVAcGnZQ...) has 21.2765957%<PHONE_NUMBER>8) of pool 36 with total reward of<PHONE_NUMBER>4
2022-07-06 12:07:20.454  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 52 leftover to the depositor: Ok(())
2022-07-06 12:07:20.454 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ c261ace62d332e9d06b5cc414dd830bd71cda1f3517de1f09ebf2e9376973f0a (GyBph4GJ...) has 9.090909% (646483196) of pool 46 with total reward of<PHONE_NUMBER>
2022-07-06 12:07:20.454 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 9080107c5b4f274e3bdb26c2d3fd525e06e892d82d6e62b9b0b811fad35d4e48 (FqnTR6YM...) has 90.9090909%<PHONE_NUMBER>) of pool 46 with total reward of<PHONE_NUMBER>
2022-07-06 12:07:20.454  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 7 leftover to the depositor: Ok(())
2022-07-06 12:07:20.454 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ eebbde3ff2bb37ca11414154e92c0521ac8051ea48d0d84b39714b2347763648 (HyLisujX...) has 0.3021148% (215222628) of pool 50 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.454 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ 684cfd19ea4f0226735f6d79116462386ec80d83581c07b4f1ae6efe0e307b1e (Ew5NJucS...) has 96.6767371%<PHONE_NUMBER>1) of pool 50 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.454 DEBUG                 main runtime::nomination-pools: [13440793] 🏊♂ e2b0f2b01464d90745aead7d1c6907d8fb7bd8c36f95996431fd36cc9e854554 (HhYuQCR1...) has 3.021148%<PHONE_NUMBER>) of pool 50 with total reward of<PHONE_NUMBER>2
2022-07-06 12:07:20.454  WARN                 main runtime::nomination-pools: [13440793] 🏊♂ paying 72 leftover to the depositor: Ok(())
2022-07-06 12:07:20.454  INFO                 main runtime::nomination-pools: [13440793] 🏊♂ Upgraded 144 members, 57 reward pools, TVL<PHONE_NUMBER>343394 TPL<PHONE_NUMBER>343394, storage to version StorageVersion(2)
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for System
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Babe
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Timestamp
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Indices
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Balances
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for TransactionPayment
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Authorship
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Staking
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Offences
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Historical
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Session
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Grandpa
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ImOnline
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for AuthorityDiscovery
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Democracy
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Council
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for TechnicalCommittee
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for PhragmenElection
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for TechnicalMembership
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Treasury
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Claims
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Utility
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Identity
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Society
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Recovery
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Vesting
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Scheduler
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Proxy
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Multisig
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Preimage
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Bounties
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ChildBounties
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Tips
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ElectionProviderMultiPhase
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Gilt
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for VoterList
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for NominationPools
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParachainsOrigin
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Configuration
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParasShared
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParaInclusion
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParaInherent
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParaScheduler
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Paras
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Initializer
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Dmp
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Ump
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Hrmp
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParaSessionInfo
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for ParasDisputes
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Registrar
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Slots
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Auctions
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ✅ no migration for Crowdloan
2022-07-06 12:07:20.454  INFO                 main runtime::frame-support: ⚠ XcmPallet declares internal migrations (which *might* execute). On-chain `StorageVersion(0)` vs current storage version `StorageVersion(0)`
2022-07-06 12:07:20.454  INFO                 main runtime::nomination-pools: [13440793] 🏊♂ post upgrade hook for MigrateToV2 executed.

bot merge

bot merge


Refactor host services

Host services need to be moved to a suitable feature location and refactored to match our current pattern as for other services in Deneb,

Test
Dev visual
Packaged visual

Update options
✅
✅

Rendering events
✅
✅

Locale (has been removed, as it should be being managed by I18nServices, but check for regressions)
✅
✅

Fetch more data
✅
✅

Selection ID generation in dataset
✅
✅

Property persistence
✅
✅

URL launching
✅
✅

Context menu + data point resolution
✅
✅

Cross-filtering
✅
✅

Cross-highlight
✅
✅

Tooltip resolution
✅
✅

Theme bindings
✅
✅

External resource warning
✅
✅

Template download
✅
✅


fix: Patch for new Form Access Protocol

Contributor checklist

[ ] Bug fixes include regression tests
[ ] Features include unit/acceptance tests

🚀 Thank you for your contribution! 🚀


Invalid library structure

I'd like to leave a note to everyone that although the folder structure is compliant with the norms of the Arduino project, the file structure is a bit messy as it contains headers alone (and no .cpp files) and hence will require rebuilding of library structure.

Have started working on the library structure.

Aah, it just doesn't affect the project anyway....
So sorry for a late comment but I've been working to get past entrance exams... A week more and I'll be back in here! 🤩😊


Disable compiler_crashers/28447-result-case-not-implemented-failed.swift

This test doesn't reproduce 100% of the time, so let's disable it.  I
filed SR-3118 to make sure we don't lose track of it.
rdar://problem/29069838

@swift-ci Please smoke test and merge.