Cloud and mountain generation

I'm not sure if the Background class should be responsible for the generation of clouds and mountains.

What do you think about a class CloudGenerator and MountainGenerator ? Both would be used by Background.
I think we should rename RandomCloud to Cloud because it really is a cloud and nothing more (same for mountains).
Moreover, I think it would be wise to have a superclass Generator. We can see some factorizable duplications in the code :

void Background::update() {
	for (int i = 0; i < this->clouds.size(); i++) {
		bool active = this->clouds.at(i)->isAlive();
		if (active) {
			this->clouds.at(i)->translate(- (scrollSpeed + 1) * cloudSpeedModifier, 0);
			this->clouds.at(i)->update();
		}
		else {
			delete(this->clouds.at(i));
			this->clouds.erase(this->clouds.begin() + i);
			i--;
		}
	}

	for (int i = 0; i < this->mountains.size(); i++) {
		bool active = this->mountains.at(i)->isAlive();
		if (active) {
			this->mountains.at(i)->translate(- scrollSpeed * mountainSpeedModifier, 0);
			this->mountains.at(i)->update();
		}
		else {
			delete(this->mountains.at(i));
			this->mountains.erase(this->mountains.begin() + i);
			i--;
		}
	}

	this->createClouds();
	this->createMountains();
}

Cloud should be an "abstract cloud" without any reference to any constant "size", "height" or "angle".  Then we define all the constant parameters in the "generators". That's what I suggest to unify all the parameters.

Yeah, I was thinking about factoring a bit of this part, but I didn't really thought about it. Moreover, I don't think it's a huge issue at this current state.
That's another thing to put on our backlog I guess 🤔

Has the problem been solved ?

no idea


Enable HTTP Compression

Many dataset hyperslab and point selections would benefit from using HTTP Compression (c.f. https://en.wikipedia.org/wiki/HTTP_compression).  For example, if  1024x1024 dataset is mostly zero's, reading the entire dataset would need to transmit relatively few bytes if the response is compressed compared to 10241024element_size for the uncompressed response.

This is implemented in https://github.com/HDFGroup/hsds/commit/d39ff5fd7b1fe81c63089af40bc78e963b3ac82b.


[Question] Access to end() iterator reference

How can I access to the reference of the .end() iterator when there is an assert that forces to avoid it?
Maybe the question could look a little bit silly but I have problems with iterators because of this, and of course commenting the assert is just a short term and dirty solution to the problem.
https://github.com/nlohmann/json/blob/186c747a19c56c3208e7539713607211b6059ceb/single_include/nlohmann/json.hpp#L5304

Could you provide an example?

We are doing a migration from rapidjson to your library:
https://github.com/KratosMultiphysics/Kratos/blob/07929fd8063e68dd39747cb9b8c13f91e949e128/kratos/includes/kratos_parameters.h
We have a custom class that uses internally your library, so for that reason we create an iterator adaptor. During the construction of our begin() and end() methods we call to the operator*(), both to the end() and begin(), but the end() iterators give us the error due to the assert.
https://github.com/KratosMultiphysics/Kratos/blob/07929fd8063e68dd39747cb9b8c13f91e949e128/kratos/includes/kratos_parameters.h#L241
https://github.com/KratosMultiphysics/Kratos/blob/07929fd8063e68dd39747cb9b8c13f91e949e128/kratos/includes/kratos_parameters.h#L895

It is illegal to dereference an end iterator, from ANY container.

You can turn off assertions by defining the preprocessor macro NDEBUG, see https://en.cppreference.com/w/cpp/error/assert. But as @gregmarr described, you must never dereference a past-the-end iterator in the first place.

Thanks, I will do that, I close this, thanks


Cancel button transmogrified following upload in Safari

Steps to reproduce:

Load the explorer in Safari
Choose "My Computer" as service type
Click "Add Files"
Choose a file and click upload
Revisit the modal where files can be chosen.
Notice the cancel button's height and the upload button's width are reduced.

Hi @ccesarz, I couldn't reproduce this error.
I have some questions to clarify the conditions:
After the step 4 click upload, the it start to upload the file. In this step, we should wait for the upload completing?
After the upload completed. The file-explorer will be closed. Step 5 Revisit the modal where files can be chosen. means re-launch the file-explorer?

Our latest release redoes this UI entirely, so we're closing this ticket.


Move to PureComponent & fix stateless irregularities

This PR has 3 goals:

Move all Components to PureComponents, to make them not update when not necessary.

This required some fixes in the Modal.spec.js, which assumed updates with no prop change.

Make all stateful components use React.PureComponent.

This replaces import React, { PureComponent } from "react" to simply use React.PureComponent.

Fix irregularities in stateless ("function") components.

The majority used the arrow function declaration, but some used regular function statements. This PR moves them all the arrow function.

React.PureComponent’s shouldComponentUpdate() only shallowly compares the objects. If these contain complex data structures, it may produce false-negatives for deeper differences. Only extend PureComponent when you expect to have simple props and state, or use forceUpdate() when you know deep data structures have changed. Or, consider using immutable objects to facilitate fast comparisons of nested data.
Furthermore, React.PureComponent’s shouldComponentUpdate() skips prop updates for the whole component subtree. Make sure all the children components are also “pure”.

Since it doesn't check context changes and also forces users to ensure all of the children components are also "pure", I don't believe this to be a good fit for this library. This library needs to be as flexible as possible and I believe this will make it more difficult to use.

I am seeing a lot of unnecessary re-rendering when using the Reactstrap components (via why-did-you-update). Since you didn't want to adopt PureComponent, do you have any plans to address this problem via shouldComponentUpdate?
You may want to reconsider using PureComponent. While it does not do a deep comparison of props or state, it DOES do a reference comparison, on each prop and state which I've found to be sufficient. PureComponent really just does some basic shouldComponentUpdate logic for you.


Issue 24: Use standard mechanism to save and restore Activity and Fragment state

You may need to add this to the travis.yml so the sdk licenses get accepted:
  licenses:
    - 'android-sdk-license-.+'
    - 'android-sdk-preview-.+'
    - '.*'


Add sop frontend

There is a standard CLI interface: https://datatracker.ietf.org/doc/html/draft-dkg-openpgp-stateless-cli-02
Implementing it will allow to run OpenPGP interoperability test suite

Duplicate of #110


clean up unused vnet peerings

JIRA link (if applicable)
DTSPO-12699
Change description
clean up unused vnet peerings
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

Ah cool will close this pr then.


Add environment name next to container in Containers section

We should add environment name next to container in Containers section

When hovering over container name, environment name is shown


Simple SOCKS fails to start occasionally

From #388 - The simple socks server sometimes doesn't accept connections until you restart.

I think @mollyling is best placed to figure this out, changing assignment. :)

Just to point out that I've been working on some integration tests for uproxy-networking and am seeing what looks like weird TCP socket behaviour on initial extension load (subsequent loads work fine). Might be related:
https://github.com/uProxy/uproxy-networking/pull/178

OK, tracked down a file-length problem to a likely mime-type issue in wup
(e.g., not our problem).  Currently tracking down tcp provider's accept()
issues.
Cheers,
$ ls
Lally Singh | Google Ideas http://www.google.com/ideas/ | Engineering |
<EMAIL_ADDRESS>On Thu, Jan 8, 2015 at 10:32 AM, trevj<EMAIL_ADDRESS>wrote:

Just to point out that I've been working on some integration tests for
uproxy-networking and am seeing what looks like weird TCP socket behaviour
on initial extension load (subsequent loads work fine). Might be
related:
uProxy/uproxy-networking#178
https://github.com/uProxy/uproxy-networking/pull/178
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/628#issuecomment-69195436.

I spent the morning looking into what I think is the accept issue as part of getting the TCP integration test to work so can take this. Sorry, didn't think the two would turn out to be related!

Super weird. This looks like a Chrome bug affecting version 41, at least, but apparently not 39. I don't see this behaviour at all in Firefox.
Here's some code:
var s = freedom['core.tcpsocket']();
s.on('onConnection', (acceptValue:freedom_TcpSocket.ConnectInfo) : void => {
  log.info('NEW CONNECTION');
});
s.listen('<IP_ADDRESS>', 9998).then(() => {
  log.info('server listening');
  var c = freedom['core.tcpsocket']();
  c.connect('<IP_ADDRESS>', 9998).then(
    () => { log.info('client connected'); },
    (e:Error) => { log.error('client could not connect: ' + e.message); });
  }, (e:Error) => { log.error('server failed to listen: ' + e.message); });

To reproduce:

Start Chrome from fresh.
Load an app containing the above code:
The JavaScript console should show server listening and client connected but nothing else.
Make a connection to the server on port 9998 using telnet:
telnet will connect but the server will never receive the onConnection event.
Now, reload the app:
The JavaScript console should show server listening and client connected and NEW CONNECTION.
Making more connections to the server via telnet will work now, too.

Expected behaviour: the server should always receive onConnection events and you should always see NEW CONNECTION in the JavaScript console.

This promises good times ahead.
Cheers,
$ ls
On Jan 8, 2015 4:11 PM, "trevj"<EMAIL_ADDRESS>wrote:

Super weird. This looks like a Chrome bug affecting version 41, at least,
but apparently not 39. I don't see this behaviour at all in Firefox.
Here's some code:
var s = freedom'core.tcpsocket';
s.on('onConnection', (acceptValue:freedom_TcpSocket.ConnectInfo) : void => {
log.info('NEW CONNECTION');
});
s.listen('<IP_ADDRESS>', 9998).then(() => {
log.info('server listening');
var c = freedom'core.tcpsocket';
c.connect('<IP_ADDRESS>', 9998).then(
() => { log.info('client connected'); },
(e:Error) => { log.error('client could not connect: ' + e.message); });
}, (e:Error) => { log.error('server failed to listen: ' + e.message); });
To reproduce:

Start Chrome from fresh.
Load an app containing the above code:

The JavaScript console should show server listening and client
connected but nothing else.
Make a connection to the server on port 9998 using telnet:
telnet will connect but the server will never receive the
onConnection event.

- Now, reload the app:
  - The JavaScript console should show server listening and client
  connected *and* NEW CONNECTION.
  - Making more connections to the server via telnet will work now,
  too.

Expected behaviour: the server should always receive onConnection events
and you should always see NEW CONNECTION in the JavaScript console.
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/628#issuecomment-69249915.

So, if I take Freedom out of the mix then I do receive the connections, in Chrome 39 and 41.
{
  "manifest_version": 2,
  "name": "accept",
  "description": "accept issue reproduce case",
  "version": "0.1",
  "app": {
    "background": {
      "scripts": [
        "background.js"
      ]
    }
  },
  "permissions": [],
  "sockets": {
    "tcp": {
      "connect" : ""
    },
    "tcpServer": {
      "listen": ""
    }
  }
}

chrome.sockets.tcpServer.create({}, function(createInfo) {
  console.log('server socket created: ' + JSON.stringify(createInfo));
  chrome.sockets.tcpServer.listen(createInfo.socketId, '<IP_ADDRESS>', 9998, function(resultCode) {
    if (resultCode < 0) {
      console.log('could not create server socket: ' + chrome.runtime.lastError.message);
      return;
    }
    console.log('server listening');
    chrome.sockets.tcpServer.onAccept.addListener(function(info) {
      console.log('NEW CONNECTION: ' + JSON.stringify(info));
    });
  });
});

Output, if I connect via telnet:
server socket created: {"socketId":1}
server listening
NEW CONNECTION: {"clientSocketId":1,"socketId":1}

Isn't it weird that the socket IDs are identical?

Oh wait maybe the socket ID namespace is distinct for server and client sockets.
Anyway, seems like something somewhere changed in Chrome 41 that is mucking up how Freedom interacts with sockets.

At this point I suspect the issue occurs when the server socket and client socket have the same ID. It doesn't always happen (right now I can't reproduce the issue using the above steps at all...very annoying!). I'll have to look at the TCP provider in Freedom a little more.

While I'm not 100% convinced we don't still have some strange weirdness going on with TCP sockets in Chrome, this specific issue has been addressed in freedom-for-chrome 0.4.11.


added new game reversi ai

PR Description 📜
The main goal in the game of Othello is to dominate the board by having the highest number of your colored disks on it when the game reaches its conclusion. The game ends when either no more legal moves can be made or when the entire board becomes filled with disks. In the end, the player who possesses the majority of disks on the board is proclaimed the winner. also named as reversi
THIS GAME IS PLAYED AGAINST AI
Fixes #2319

Mark the task you have completed ✅

[ ✅ ] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[  ✅ ] I have performed a self-review of my own code or work.
[ ✅ ] I have commented my code, particularly in hard-to-understand areas.
[ ✅ ] My changes generates no new warnings.
[✅ ] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[ ✅] I have added screenshot for website preview in assets/images
[✅ ] I have added entries for my game in main README.md
[✅ ] I have added README.md in my folder
[✅ ] I have added working video of the game in README.md (optional)
[✅ ] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @RitiChandak ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

I sincerely apologize for forgetting to make the necessary changes

The game already exists on GameZone!
And we don't accept duplicate games, you can do enhancement in the already existing game.

Thank you  @RitiChandak , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

@daccdacc  so i have to add this code to the existing game ?


label attribute doesn't work

I think line 156
val lbl = attrs.find(_.a.name == "label").getOrElse(play.api.i18n.Messages(f.label)).toString
should be
val lbl = attrs.find(_.a.name == "label").map(_.v).getOrElse(play.api.i18n.Messages(f.label)).toString
In my testing,
        pForm(routes.AsisCtrl.search())(Seq(
          inputText(searchForm("searchTerm"), Seq(
            cls := "search-query",
            placeholder := "uwid or userid or ...",
            "showConstraints".attr := "false",
            "label".attr := "MyLabel")))),

displays
AttrPair(Attr(label),MyLabel,scalatags.Text$GenericAttr@4a0422f0)
rather than
MyLabel

Hi @bwbecker thanks :)
Would you like to raise a PR?
Also make it:
val lbl = attrs.find(_.a.name == "label").map(_.v).getOrElse(play.api.i18n.Messages(f.label))

Again, Thanks :+1:

That’s a lot of overhead for a simple fix.  Just go ahead and do it.
Byron

On Jan 24, 2015, at 1:21 AM, Saurabh Rawat<EMAIL_ADDRESS>wrote:
Hi @bwbecker https://github.com/bwbecker thanks :)
Would you like to raise a PR?
Also make it:
val lbl = attrs.find(.a.name == "label").map(.v).getOrElse(play.api.i18n.Messages(f.label))
Again, Thanks
—
Reply to this email directly or view it on GitHub https://github.com/eklavya/playtags/issues/1#issuecomment-71302460.

Byron Weber Becker
School of Computer Science
University of Waterloo, Waterloo, Ontario  N2L 3G1
Email<EMAIL_ADDRESS>Phone:<PHONE_NUMBER> x34661
Fax:<PHONE_NUMBER> (include my email on cover page)
Advising FAQ:  www.cs.uwaterloo.ca/current/faq

Well clearly you haven't read about the quick github patch feature. Anyways, thanks for reporting.

Nope.  Feel free to enlighten me.

On Jan 24, 2015, at 5:19 AM, Saurabh Rawat<EMAIL_ADDRESS>wrote:
Well clearly you haven't read about the quick github patch feature. Anyways, thanks for reporting.
—
Reply to this email directly or view it on GitHub https://github.com/eklavya/playtags/issues/1#issuecomment-71309310.

Byron Weber Becker
School of Computer Science
University of Waterloo, Waterloo, Ontario  N2L 3G1
Email<EMAIL_ADDRESS>Phone:<PHONE_NUMBER> x34661
Fax:<PHONE_NUMBER> (include my email on cover page)
Advising FAQ:  www.cs.uwaterloo.ca/current/faq

Well you just click on edit on the file you want to edit, edit it and that's all you have to do. It forks the repo and submits a PR. If you want to submit a PR now, please go ahead and do it.

Thanks for the tip.  I’ll try that if another one comes up.
Byron

On Jan 24, 2015, at 5:30 AM, Saurabh Rawat<EMAIL_ADDRESS>wrote:
Well you just click on edit on the file you want to edit, edit it and that's all you have to do. It forks the repo and submits a PR. If you want to submit a PR now, please go ahead and do it.
—
Reply to this email directly or view it on GitHub https://github.com/eklavya/playtags/issues/1#issuecomment-71309789.

Byron Weber Becker
School of Computer Science
University of Waterloo, Waterloo, Ontario  N2L 3G1
Email<EMAIL_ADDRESS>Phone:<PHONE_NUMBER> x34661
Fax:<PHONE_NUMBER> (include my email on cover page)
Advising FAQ:  www.cs.uwaterloo.ca/current/faq


Updated OWNERS file for release-2.7

https://issues.redhat.com/browse/ACM-2363
Signed-off-by: dislbenn<EMAIL_ADDRESS>

/retest

/retest

/retest

/override ci/prow/e2e-kind
Overriding this job since this PR is to update the OWNERS file for this repo. We will need to debug the failure at a later time.


Get kinds list from datastore

Hi,
I'd like to retrieve a complete list of kinds from datastore.
There' s any way using gcloud-node?
thanks in advance

@pcostell

AFAIK there actually isn't a reliable way to do that in an authoritative way. I believe we have a cache of the Kinds (updated every so often, for the UI), but it's not a reliable strongly-consistent method of figuring out which kinds are in your Datastore...

hi,
thanks @jgeewax for the quick reply.
There's any intention to implement this basic functionality in the future? and if the response is yes there are any deadlines?
thanks

You can do this with a [metadata query][https://cloud.google.com/datastore/docs/concepts/metadataqueries#kind_queries].
There is a snippet there that shows how to get a list of all kinds. This queries your actual data so it will be up-to-date, but as with other global queries it will be impacted by eventual consistency.

@pcostell Great!
Thanks for the answer!


[ISSUE-135][FOLLOWUP][Improvement][AQE] Assign adjacent partitions to the same ShuffleServer

What changes were proposed in this pull request?
Follow issue#136, allocate adjacent partitions to the same ShuffleServer. When the client calls getShuffleResultForMultiPart, the number of ShuffleServer requests is minimized
Why are the changes needed?
Bring some performance improvement
Does this PR introduce any user-facing change?
No
How was this patch tested?
UT

Spark usually start the task one by one, If we have 700 reduce tasks, 7 shuffle server, we usually start 0 - 99 task first. 0 - 99 reduce will be allocated to shuffle server 0. Will it increase too much pressure for shuffle server 0? So I think origin implement may be useful for some situation. It's better to let users to choose which strategy is most suitable. We should separate the mechanism from strategy, let configuration to decide which way we want. It's ok for me about server's configuration or client's configuration.

Good idea.

We should allocate continuous n reduce partitions to one shuffle server to avoid that too many task read the same    shuffle server.  If we have 700 reduce tasks,  our concurrency is 100, we usually start 0 - 99 task first. if we allocate 10 continuous reduce partitions to one shuffle server, shuffle server 0 will have [0, 9] [80, 89] reduce partitions, shuffle server 1 will have [ 10, 19], [90, 99] reduce partition, shuffle server 3 will have [20, 29],[100, 109] reduce partition ....
We also need some performance test.

We should allocate continuous n reduce partitions to one shuffle server to avoid that too many task read the same shuffle server. If we have 700 reduce tasks, our concurrency is 100, we usually start 0 - 99 task first. if we allocate 10 continuous reduce partitions to one shuffle server, shuffle server 0 will have [0, 9] [80, 89] reduce partitions, shuffle server 1 will have [ 10, 19], [90, 99] reduce partition, shuffle server 3 will have [20, 29],[100, 109] reduce partition .... We also need some performance test.

How to decide how many contiguous partitions need to be allocated, like 10 mentioned above.

Like the above example, if assigning 7 consecutive partitions is the best, for example [0,6] is assigned to server1, [7,12] is assigned to server2, but we do not know the number of concurrent tasks.

We can read the executor configuration of spark through configuration, but the actual app running process may not be able to allocate so many resources.

We can read the executor configuration of spark through configuration, but the actual app running process may not be able to allocate so many resources.

If we use dynamic allocation, we can't know the number of executors. So I think we can give a configuration first, user can set that value. Similarly ByteDance Shuffle Service give the concurrency tasks through an experience formula, you can see https://github.com/bytedance/CloudShuffleService/blob/ef0ffb3f43f9f6e96af49629aed2a6ce61a6a2ab/spark-shuffle-manager-2/src/main/scala/org/apache/spark/shuffle/css/CssShuffleManager.scala#L64

Like the above example, if assigning 7 consecutive partitions is the best, for example [0,6] is assigned to server1, [7,12] is assigned to server2, but we do not know the number of concurrent tasks.

Maybe there are no difference between 7 and 10. We should need some performance tests here.

Codecov Report

Merging #307 (edf838f) into master (cf63eae) will increase coverage by 0.26%.
The diff coverage is 87.41%.

@@             Coverage Diff              @@
##             master     #307      +/-   ##
============================================
+ Coverage     60.73%   60.99%   +0.26%
- Complexity     1462     1490      +28
============================================
  Files           180      185       +5
  Lines          9229     9315      +86
  Branches        887      901      +14
============================================
+ Hits           5605     5682      +77
- Misses         3325     3329       +4
- Partials        299      304       +5

Impacted Files
Coverage Δ

...apache/hadoop/mapreduce/v2/app/RssMRAppMaster.java
0.00% <ø> (ø)

...he/uniffle/client/impl/ShuffleWriteClientImpl.java
21.23% <ø> (ø)

...rg/apache/uniffle/client/util/RssClientConfig.java
0.00% <ø> (ø)

...java/org/apache/uniffle/common/util/Constants.java
0.00% <ø> (ø)

...he/uniffle/coordinator/CoordinatorGrpcService.java
2.29% <0.00%> (-0.02%)
:arrow_down:

...oordinator/PartitionBalanceAssignmentStrategy.java
94.82% <60.00%> (-3.64%)
:arrow_down:

...org/apache/spark/shuffle/RssSparkShuffleUtils.java
54.54% <78.57%> (+5.33%)
:arrow_up:

...g/apache/uniffle/coordinator/CoordinatorUtils.java
72.60% <79.31%> (+7.38%)
:arrow_up:

...niffle/coordinator/AbstractAssignmentStrategy.java
87.09% <82.60%> (-4.34%)
:arrow_down:

.../coordinator/PerferDiffHostAssignmentStrategy.java
92.85% <92.85%> (ø)

... and 9 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

Like the above example, if assigning 7 consecutive partitions is the best, for example [0,6] is assigned to server1, [7,12] is assigned to server2, but we do not know the number of concurrent tasks.

Maybe there are no difference between 7 and 10. We should need some performance tests here.

I will make some  performance tests later.

We can read the executor configuration of spark through configuration, but the actual app running process may not be able to allocate so many resources.

If we use dynamic allocation, we can't know the number of executors. So I think we can give a configuration first, user can set that value. Similarly ByteDance Shuffle Service give the concurrency tasks through an experience formula, you can see https://github.com/bytedance/CloudShuffleService/blob/ef0ffb3f43f9f6e96af49629aed2a6ce61a6a2ab/spark-shuffle-manager-2/src/main/scala/org/apache/spark/shuffle/css/CssShuffleManager.scala#L64

Yes. This optimization has been applied in our internal uniffle, it works well.

We would better modify the document https://github.com/apache/incubator-uniffle/blob/master/docs/client_guide.md#support-spark-aqe , too.

I reused the environment in https://github.com/apache/incubator-uniffle/pull/190 to compare the performance before and after issue#136, and the performance improvement after merging the PR
Environment
Shuffle Server Num : 5
Shuffle Write: 48G
Configuration: --conf spark.sql.shuffle.partitions=5000 --conf spark.sql.adaptive.enabled=true --conf spark.sql.adaptive.shuffle.targetPostShuffleInputSize=64MB --conf spark.dynamicAllocation.maxExecutors=200 --conf spark.executor.cores=6
We measure the performance of get_shuffle_result by the following metrics:

get_shuffle_result_times: The number of calls of the get_shuffle_result interface
get_shuffle_result_cost: Time consumption of get_shuffle_result interface
get_shuffle_result_for_multi_part_times:The number of calls of the get_shuffle_result_for_multi_part interface
get_shuffle_result_for_multi_part_cost: Time consumption of get_shuffle_result_for_multi_part interface

Test Results
Before issue_136

serverId
get_shuffle_result_times
get_shuffle_result_cost(ms)

Server1
1000
157614

Server2
1000
426897

Server3
1000
269488

Server4
1000
906758

Server5
1001
123217

sum
5001
1883974

After issue_136

serverId
get_shuffle_result_for_multi_part_times
get_shuffle_result_for_multi_part_cost(ms)

Server1
833
870720

Server2
833
260865

Server3
834
333202

Server4
833
90277

Server5
835
94113

sum
4168
1649177

After this pr

serverId
get_shuffle_result_for_multi_part_times
get_shuffle_result_for_multi_part_cost(ms)

Server1
168
40355

Server2
167
43852

Server3
167
98452

Server4
167
91838

Server5
168
25479

sum
837
299976

Summarize
After this pr, the number of interface requests is reduced by 79.9%, and the total time is reduced by 81.8%.

We can read the executor configuration of spark through configuration, but the actual app running process may not be able to allocate so many resources.

If we use dynamic allocation, we can't know the number of executors. So I think we can give a configuration first, user can set that value. Similarly ByteDance Shuffle Service give the concurrency tasks through an experience formula, you can see https://github.com/bytedance/CloudShuffleService/blob/ef0ffb3f43f9f6e96af49629aed2a6ce61a6a2ab/spark-shuffle-manager-2/src/main/scala/org/apache/spark/shuffle/css/CssShuffleManager.scala#L64

Yes. This optimization has been applied in our internal uniffle, it works well.

Maybe this feature can also be applied to the community, I think it's a good feature.

We can read the executor configuration of spark through configuration, but the actual app running process may not be able to allocate so many resources.

If we use dynamic allocation, we can't know the number of executors. So I think we can give a configuration first, user can set that value. Similarly ByteDance Shuffle Service give the concurrency tasks through an experience formula, you can see https://github.com/bytedance/CloudShuffleService/blob/ef0ffb3f43f9f6e96af49629aed2a6ce61a6a2ab/spark-shuffle-manager-2/src/main/scala/org/apache/spark/shuffle/css/CssShuffleManager.scala#L64

Yes. This optimization has been applied in our internal uniffle, it works well.

Maybe we can apply this feature to our community and estimate the number of ShuffleServers needed according to the number of concurrent tasks.

We can read the executor configuration of spark through configuration, but the actual app running process may not be able to allocate so many resources.

If we use dynamic allocation, we can't know the number of executors. So I think we can give a configuration first, user can set that value. Similarly ByteDance Shuffle Service give the concurrency tasks through an experience formula, you can see https://github.com/bytedance/CloudShuffleService/blob/ef0ffb3f43f9f6e96af49629aed2a6ce61a6a2ab/spark-shuffle-manager-2/src/main/scala/org/apache/spark/shuffle/css/CssShuffleManager.scala#L64

Yes. This optimization has been applied in our internal uniffle, it works well.

Maybe we can apply this feature to our community and estimate the number of ShuffleServers needed according to the number of concurrent tasks.

Would you contribute this feature and let the @zuston help you review this feature?

I'm grad to review this feature if you want  @leixm

I'm grad to review this feature if you want @leixm

Thank you, i will raise a pr for this feature.


Protobuf "info" map fields take too much memory

Every VG protobuf message has a "map<string, Info> info" field.  On my system, this field, takes 88 bytes in memory when empty, and amounts to more than half of the in-memory protobuf Graph representation. And probably matches a good chunk of the memory used by the various hash_map indexes (if we assume 2 * 8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary.  I'd suggest getting rid of it if possible, or moving it into Graph-level maps - ie instead of having an info record per Node, have a map in Graph that maps node id's to info records.  This seems to me to be a low-hanging-fruit way to cut memory usage by about half.  Something I can do, but would like feedback on as I don't really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string, ::vg::Info, ::google::protobuf::internal::WireFormatLite::TYPE_STRING, ::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn

Woah! I'm surprised that they take space at all when they are empty. But
this is in-memory, so I guess the implementation requires it.
I think you are right. If everything has an ID then we can selectively
annotate pieces of the graph efficiently. But is there another way?
On Jul 22, 2015 7:47 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Every VG protobuf message has a "map info" field. On my system, this
field, takes 88 bytes in memory when empty, and amounts to more than half
of the in-memory protobuf Graph representation. And probably matches a good
chunk of the memory used by the various hash_map indexes (if we assume 2 *
8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary. I'd suggest getting rid of it
if possible, or moving it into Graph-level maps - ie instead of having an
info record per Node, have a map in Graph that maps node id's to info
records. This seems to me to be a low-hanging-fruit way to cut memory usage
by about half. Something I can do, but would like feedback on as I don't
really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string, ::vg::Info,
::google::protobuf::internal::WireFormatLite::TYPE_STRING,
::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58.

Yeah, surprised me too, but when a 40M vg file was taking ~4G memory just
to load the protobuf something seemed fishy.
Not sure if there's another way.  Would be nice if the maps were pointers
in memory, but doesn't seem to be the case.  Protobuf doc says you can't
make map fields optional or required either (don't know enough about
protobuf to know if that would help anyway).
I guess not having an "id" field for every record makes implementing
graph-level maps more of hassle but should still be doable in many cases
(ie a mapping could be its index in the path list (which would need to be
transformed as graphs streamed in and out) etc.).   But even adding id
fields seems like a win to get rid of the maps.
On Wed, Jul 22, 2015 at 1:50 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Woah! I'm surprised that they take space at all when they are empty. But
this is in-memory, so I guess the implementation requires it.
I think you are right. If everything has an ID then we can selectively
annotate pieces of the graph efficiently. But is there another way?
On Jul 22, 2015 7:47 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Every VG protobuf message has a "map info" field. On my system, this
field, takes 88 bytes in memory when empty, and amounts to more than half
of the in-memory protobuf Graph representation. And probably matches a
good
chunk of the memory used by the various hash_map indexes (if we assume 2

8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary. I'd suggest getting rid of
it
if possible, or moving it into Graph-level maps - ie instead of having an
info record per Node, have a map in Graph that maps node id's to info
records. This seems to me to be a low-hanging-fruit way to cut memory
usage
by about half. Something I can do, but would like feedback on as I don't
really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string, ::vg::Info,
::google::protobuf::internal::WireFormatLite::TYPE_STRING,
::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123806346.

There is a way to make a dynamic version of xg. It isn't pretty to code but
would theoretically work. We can discuss. This seems like an easy win
though. I am not attached to the info objects.
On Jul 22, 2015 8:04 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Yeah, surprised me too, but when a 40M vg file was taking ~4G memory just
to load the protobuf something seemed fishy.
Not sure if there's another way. Would be nice if the maps were pointers
in memory, but doesn't seem to be the case. Protobuf doc says you can't
make map fields optional or required either (don't know enough about
protobuf to know if that would help anyway).
I guess not having an "id" field for every record makes implementing
graph-level maps more of hassle but should still be doable in many cases
(ie a mapping could be its index in the path list (which would need to be
transformed as graphs streamed in and out) etc.). But even adding id
fields seems like a win to get rid of the maps.
On Wed, Jul 22, 2015 at 1:50 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Woah! I'm surprised that they take space at all when they are empty. But
this is in-memory, so I guess the implementation requires it.
I think you are right. If everything has an ID then we can selectively
annotate pieces of the graph efficiently. But is there another way?
On Jul 22, 2015 7:47 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Every VG protobuf message has a "map info" field. On my system, this
field, takes 88 bytes in memory when empty, and amounts to more than
half
of the in-memory protobuf Graph representation. And probably matches a
good
chunk of the memory used by the various hash_map indexes (if we assume
2

8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary. I'd suggest getting rid of
it
if possible, or moving it into Graph-level maps - ie instead of having
an
info record per Node, have a map in Graph that maps node id's to info
records. This seems to me to be a low-hanging-fruit way to cut memory
usage
by about half. Something I can do, but would like feedback on as I
don't
really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string,
::vg::Info,
::google::protobuf::internal::WireFormatLite::TYPE_STRING,
::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123806346.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123811500.

It just occurred to me that there is a simple hack to turn the maps into
pointers:  Just wrap the map in a new message... Ex:
message Metadata {
map<string, Info> info = 1;
}
message Node {
string sequence = 1;   // sequence
string name = 2;  // a name provides an identifier
int64 id = 3;     // ids are critical, and unique within a graph
bytes data = 4;   // arbitrary data
Metadata metadata = 5;
}
Shaves 80 bytes off node as metadata will be stored as a pointer.
On Wed, Jul 22, 2015 at 2:04 PM, Glenn Hickey<EMAIL_ADDRESS>wrote:

Yeah, surprised me too, but when a 40M vg file was taking ~4G memory just
to load the protobuf something seemed fishy.
Not sure if there's another way.  Would be nice if the maps were pointers
in memory, but doesn't seem to be the case.  Protobuf doc says you can't
make map fields optional or required either (don't know enough about
protobuf to know if that would help anyway).
I guess not having an "id" field for every record makes implementing
graph-level maps more of hassle but should still be doable in many cases
(ie a mapping could be its index in the path list (which would need to be
transformed as graphs streamed in and out) etc.).   But even adding id
fields seems like a win to get rid of the maps.
On Wed, Jul 22, 2015 at 1:50 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Woah! I'm surprised that they take space at all when they are empty. But
this is in-memory, so I guess the implementation requires it.
I think you are right. If everything has an ID then we can selectively
annotate pieces of the graph efficiently. But is there another way?
On Jul 22, 2015 7:47 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Every VG protobuf message has a "map info" field. On my system, this
field, takes 88 bytes in memory when empty, and amounts to more than
half
of the in-memory protobuf Graph representation. And probably matches a
good
chunk of the memory used by the various hash_map indexes (if we assume
2 *
8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary. I'd suggest getting rid of
it
if possible, or moving it into Graph-level maps - ie instead of having
an
info record per Node, have a map in Graph that maps node id's to info
records. This seems to me to be a low-hanging-fruit way to cut memory
usage
by about half. Something I can do, but would like feedback on as I don't
really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string,
::vg::Info,
::google::protobuf::internal::WireFormatLite::TYPE_STRING,
::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123806346.

Oops, now see that Adam proposed doing exactly this in an email thread
yesterday that I somehow didn't read all of at the time.
On Wed, Jul 22, 2015 at 3:04 PM, Glenn Hickey<EMAIL_ADDRESS>wrote:

It just occurred to me that there is a simple hack to turn the maps into
pointers:  Just wrap the map in a new message... Ex:
message Metadata {
map<string, Info> info = 1;
}
message Node {
string sequence = 1;   // sequence
string name = 2;  // a name provides an identifier
int64 id = 3;     // ids are critical, and unique within a graph
bytes data = 4;   // arbitrary data
Metadata metadata = 5;
}
Shaves 80 bytes off node as metadata will be stored as a pointer.
On Wed, Jul 22, 2015 at 2:04 PM, Glenn Hickey<EMAIL_ADDRESS>wrote:

Yeah, surprised me too, but when a 40M vg file was taking ~4G memory just
to load the protobuf something seemed fishy.
Not sure if there's another way.  Would be nice if the maps were pointers
in memory, but doesn't seem to be the case.  Protobuf doc says you can't
make map fields optional or required either (don't know enough about
protobuf to know if that would help anyway).
I guess not having an "id" field for every record makes implementing
graph-level maps more of hassle but should still be doable in many cases
(ie a mapping could be its index in the path list (which would need to be
transformed as graphs streamed in and out) etc.).   But even adding id
fields seems like a win to get rid of the maps.
On Wed, Jul 22, 2015 at 1:50 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Woah! I'm surprised that they take space at all when they are empty. But
this is in-memory, so I guess the implementation requires it.
I think you are right. If everything has an ID then we can selectively
annotate pieces of the graph efficiently. But is there another way?
On Jul 22, 2015 7:47 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Every VG protobuf message has a "map info" field. On my system, this
field, takes 88 bytes in memory when empty, and amounts to more than
half
of the in-memory protobuf Graph representation. And probably matches a
good
chunk of the memory used by the various hash_map indexes (if we assume
2 *
8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary. I'd suggest getting rid
of it
if possible, or moving it into Graph-level maps - ie instead of having
an
info record per Node, have a map in Graph that maps node id's to info
records. This seems to me to be a low-hanging-fruit way to cut memory
usage
by about half. Something I can do, but would like feedback on as I
don't
really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string,
::vg::Info,
::google::protobuf::internal::WireFormatLite::TYPE_STRING,
::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123806346.

But the metadata shouldn
On Wed, Jul 22, 2015 at 8:04 PM, Glenn Hickey<EMAIL_ADDRESS>wrote:

It just occurred to me that there is a simple hack to turn the maps into
pointers: Just wrap the map in a new message... Ex:
message Metadata {
map<string, Info> info = 1;
}
message Node {
string sequence = 1; // sequence
string name = 2; // a name provides an identifier
int64 id = 3; // ids are critical, and unique within a graph
bytes data = 4; // arbitrary data
Metadata metadata = 5;
}
Shaves 80 bytes off node as metadata will be stored as a pointer.
On Wed, Jul 22, 2015 at 2:04 PM, Glenn Hickey<EMAIL_ADDRESS>wrote:

Yeah, surprised me too, but when a 40M vg file was taking ~4G memory just
to load the protobuf something seemed fishy.
Not sure if there's another way. Would be nice if the maps were pointers
in memory, but doesn't seem to be the case. Protobuf doc says you can't
make map fields optional or required either (don't know enough about
protobuf to know if that would help anyway).
I guess not having an "id" field for every record makes implementing
graph-level maps more of hassle but should still be doable in many cases
(ie a mapping could be its index in the path list (which would need to be
transformed as graphs streamed in and out) etc.). But even adding id
fields seems like a win to get rid of the maps.
On Wed, Jul 22, 2015 at 1:50 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

Woah! I'm surprised that they take space at all when they are empty. But
this is in-memory, so I guess the implementation requires it.
I think you are right. If everything has an ID then we can selectively
annotate pieces of the graph efficiently. But is there another way?
On Jul 22, 2015 7:47 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

Every VG protobuf message has a "map info" field. On my system, this
field, takes 88 bytes in memory when empty, and amounts to more than
half
of the in-memory protobuf Graph representation. And probably matches a
good
chunk of the memory used by the various hash_map indexes (if we assume
2 *
8 * 1.78 bytes per dense_map entry).
The info field doesn't seem super necessary. I'd suggest getting rid
of
it
if possible, or moving it into Graph-level maps - ie instead of having
an
info record per Node, have a map in Graph that maps node id's to info
records. This seems to me to be a low-hanging-fruit way to cut memory
usage
by about half. Something I can do, but would like feedback on as I
don't
really know the intuition behind these info fields...
sizeof( ::google::protobuf::internal::MapField<::std::string,
::vg::Info,
::google::protobuf::internal::WireFormatLite::TYPE_STRING,
::google::protobuf::internal::WireFormatLite::TYPE_MESSAGE, 0 >) = 88
sizeof(vg::Node) = 152
sizeof(vg::Edge) = 144
thanks
-Glenn
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123806346.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-123828772.

I'm not sure I was on that thread!
In any case, I like this solution. The info is only used in a handful of places and it will be easy to make the switch. Have you had a chance to test it?
So on the wire, protobuf is nice and small because these structures don't end up getting serialized at all. My mistake was to not profile the in-memory performance.

Yeah, wrapping it in a message does indeed turn it into a pointer, at least
on my system.  This is what happens to the Position inside Mapping, as
well.  So easy switch.
The protobuf in-memory performance is a little surprising compared to how
great it does on disk.  There seems to be 24 bytes of (constant,
unavoidable) overhead per message object.  8 bytes of which comes from a
bool ( is_default_instance) that they stick on top of the generated class
definitions.  If it grouped user-defined bools beside it, it would get
aligned out in many cases (like Edge), but the protobuf compiler aligns
user-defined bools together at the end of the definition no matter what
(at least on my system).  Would be nice to have a minimal in-memory
interface perhaps at the cost of I/O performance, but I'd guess they'd
argue that's on the client to deal with.
On Thu, Jul 23, 2015 at 6:18 AM, Erik Garrison<EMAIL_ADDRESS>wrote:

I'm not sure I was on that thread!
In any case, I like this solution. The info is only used in a handful of
places and it will be easy to make the switch. Have you had a chance to
test it?
So on the wire, protobuf is nice and small because these structures don't
end up getting serialized at all. My mistake was to not profile the
in-memory performance.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-124047395.

This is not very nice. Switching to another in-memory format might make sense. If I had known about it before, I probably would have used https://capnproto.org/.
I hadn't intended vg::VG as an interface for very large graphs. Pretty much everything I'm doing with it is chunked or over very small regions of the graph. This said, the memory heaviness certainly can't help performance.

@glennhickey have you tried moving vg to using the non-embedded maps? If not then I'll work on this.

No, haven't started that yet.
thanks!
On Fri, Jul 24, 2015 at 2:51 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

@glennhickey https://github.com/glennhickey have you tried moving vg to
using the non-embedded maps? If not then I'll work on this.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-124626463.

I should be able to test quickly. There is only one place where the info
field is used. It is for path annotation.
On Jul 24, 2015 9:08 PM, "Glenn Hickey"<EMAIL_ADDRESS>wrote:

No, haven't started that yet.
thanks!
On Fri, Jul 24, 2015 at 2:51 PM, Erik Garrison<EMAIL_ADDRESS>wrote:

@glennhickey https://github.com/glennhickey have you tried moving vg
to
using the non-embedded maps? If not then I'll work on this.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-124626463.

—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-124642785.

Just now working through Adam's cycle PR. I should get to this next.
Then, xg.

Should resolve this.
Before:
➜  test git:(master) ✗ vg construct -r 1mb1kgp/z.fa -v 1mb1kgp/z.vcf.gz -m 50 >z.vg
➜  test git:(master) ✗ /usr/bin/time -v vg stats z.vg 2>&1 | grep Maximum
        Maximum resident set size (kbytes): 251080

After:
➜  test git:(master) ✗ /usr/bin/time -v vg stats z.vg 2>&1 | grep Maximum
        Maximum resident set size (kbytes): 126672

Nice.

Awesome!
On Tue, Aug 11, 2015 at 11:34 AM, Erik Garrison<EMAIL_ADDRESS>wrote:

Should resolve this.
Before:
➜  test git:(master) ✗ vg construct -r 1mb1kgp/z.fa -v 1mb1kgp/z.vcf.gz -m 50 >z.vg
➜  test git:(master) ✗ /usr/bin/time -v vg stats z.vg 2>&1 | grep Maximum
Maximum resident set size (kbytes): 251080
After:
➜  test git:(master) ✗ /usr/bin/time -v vg stats z.vg 2>&1 | grep Maximum
Maximum resident set size (kbytes): 126672
Nice.
—
Reply to this email directly or view it on GitHub
https://github.com/ekg/vg/issues/58#issuecomment-129931836.


Thanks, bug report and integration

Hello @julr, thanks a lot for this little tool, as been of great help to add ANT HRM data to my stream.
I also want to report a bug related with my sensor (I think) listed as "ANT USBStick2", just got it from Amazon. It works, but the ID never gets detected, latest libusb-win32 driver installed using Zadig. I can still use it using 0 as sensor ID, works great!
Finally I wanted to ask for an integration with Cardia, that will emulate a electrocardiogram activity with the information. I think that project is also in C#. Having a PR there would be great! I'll do it myself but I'm not very proficient at C#.
Thanks again for this!

Thanks for your report.
The search functionality is actually done by the USB dongle itself. However the search timeout is configured (hard coded) to be 30 seconds (see ant-net/Device/HeartRateMonitor.cs#L18
) which I took from specification but this seems to be to short with your device combo. I will make this configurable the next time I work on it. However if it works with id 0 then you can use that as a "workaround" if there are no other ANT+ sensors in receiving range. It will just take a little longer to initially connect, that's all. Or you can try to search multiple times until it is found.
Regarding the integration to Cardia, I sadly don't have time for this but this project is already split up between the UI/App and the actually handling of the ANT+ receiver and sensors. It should be rather straight forward to use the ANT+ .Net Library to add support.

Thanks for your quick reply, indeed after pressing it a couple of times the sensor ID was found and now is working even faster and saving the ID, also saving me time on each use. Thanks again and I will try to implement it as soon as I have a Windows VM running with VS.


Clippy and fmt

Codecov Report
Attention: Patch coverage is 61.53846% with 110 lines in your changes missing coverage. Please review.

Project coverage is 70.74%. Comparing base (972295b) to head (5f45853).

Files
Patch %
Lines

src/ucsc/types/blat.rs
4.34%
22 Missing :warning:

src/blast/types/conf.rs
58.33%
10 Missing :warning:

src/lib.rs
0.00%
10 Missing :warning:

src/blast/types/result.rs
22.22%
7 Missing :warning:

src/ensembl/functions/reference.rs
0.00%
7 Missing :warning:

src/utils/fasta.rs
0.00%
7 Missing :warning:

src/enrichr/types/enrich.rs
0.00%
6 Missing :warning:

src/archs4/types/correlation.rs
0.00%
5 Missing :warning:

src/archs4/types/tissue.rs
50.00%
5 Missing :warning:

src/enrichr/types/library.rs
0.00%
5 Missing :warning:

... and 10 more

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #202      +/-   ##
==========================================
+ Coverage   70.46%   70.74%   +0.27%
==========================================
  Files          63       63
  Lines        2729     2683      -46
==========================================
- Hits         1923     1898      -25
+ Misses        806      785      -21

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Support for multiple war files

Summary
I am trying to solve the issue#134 so that multiple war files can be deployed.
Use Cases

if only one war file, same as previous design.
if two or more war files in the application path /workspace, use /workspace as the webapps/ and explode war files into folders with same war file's name without file extension.

Checklist

[ ] I have viewed, signed, and submitted the Contributor License Agreement.
[ ] I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
[ ] I have added an integration test, if necessary.
[ ] I have reviewed the styleguide for guidance on my code quality.
[ ] I'm happy with the commit history on this PR (I have rebased/squashed as needed).

I tested this but had issues with detection.
My test had a directory with two WAR files in it. I did a pack build -p ./dir-with-warfiles and had issues with detection. The Tomcat buildpack output:
PASSED: a WEB-INF directory was not found, this is normal when building from source

So I think it is going down the path of doing a build from source code, but this isn't a source code build.
What are the test cases that you tried? Were you building from source? If you have a project that produces multiple WAR files and could share it, that would help with testing.
There are five scenarios that come up in my head that we need to make sure work here:

Build from source, produces a single WAR
Build from source, produces multiple WAR files
Precompiled assets single WAR with path pointing to the WAR, this is presented to the buildpacks as an exploded WAR directory
Precompiled assets path pointing to a directory with multiple WAR files in it, buildpacks see the same
Precompiled assets path pointing to a directory with a single WAR file in it, buildpacks will see the WAR file not an exploded WAR.

Let me know if you have questions about those scenarios.
@dmikusa, thank you so much for providing above testing cases. I am working on a testing repository. I will let you know when it is done.

@dmikusa, could you please review the code change and test the sample repo?
https://github.com/Weirong-Zhu/cnb-tomcat-example.

Apologies. You're on my list of PRs to review, but it's been busy lately. I promise I'll get to this as soon as I can.

Again, sorry for taking so long to review this.
I did some testing:

Build from source, produces a single WAR ✅
Build from source, produces multiple WAR files ✅
Precompiled assets single WAR with path pointing to the WAR, this is presented to the buildpacks as an exploded WAR directory ✅
Precompiled assets path pointing to a directory with multiple WAR files in it, buildpacks see the same 💥
Precompiled assets path pointing to a directory with a single WAR file in it, buildpacks will see the WAR file not an exploded WAR. 💥

The last two situations fail because detection criteria do not take this situation into consideration, so you'll see it output:
PASSED: a WEB-INF directory was not found, this is normal when building from source

and then fail cause it can't put together a buildplan. If the buildpack gets a directory of WAR files (precompiled), then it needs to handle this as well.
How would you like to proceed here? You can either push an update to this PR to address the last two cases, or I can merge what we have and I can follow up with a PR to make these last two cases work. I'm OK merging what you have, if you want to go that route, because the existing cases continue to work, and this is adding support for one of the new cases. Let me know what you'd prefer.
Thanks

Again, sorry for taking so long to review this.
I did some testing:

Build from source, produces a single WAR ✅
Build from source, produces multiple WAR files ✅
Precompiled assets single WAR with path pointing to the WAR, this is presented to the buildpacks as an exploded WAR directory ✅
Precompiled assets path pointing to a directory with multiple WAR files in it, buildpacks see the same 💥
Precompiled assets path pointing to a directory with a single WAR file in it, buildpacks will see the WAR file not an exploded WAR. 💥

The last two situations fail because detection criteria do not take this situation into consideration, so you'll see it output:
PASSED: a WEB-INF directory was not found, this is normal when building from source

and then fail cause it can't put together a buildplan. If the buildpack gets a directory of WAR files (precompiled), then it needs to handle this as well.
How would you like to proceed here? You can either push an update to this PR to address the last two cases, or I can merge what we have and I can follow up with a PR to make these last two cases work. I'm OK merging what you have, if you want to go that route, because the existing cases continue to work, and this is adding support for one of the new cases. Let me know what you'd prefer.
Thanks
@dmikusa, thanks a lot for reviewing this PR. I would like merging it first, since I do not know how to reproduce the last two cases. So, could you please give me some instructions to tackle these two cases? By the way, do you mind if I directly contact you in slack?

I would like merging it first, since I do not know how to reproduce the last two cases.

👍

So, could you please give me some instructions to tackle these two cases?

1.mkdir single-war
2. ./mvnw package one of your apps or a Paketo sample app
3. Move that into the single-war/ directory
4. pack build -p ./single-war/ and include all the other options for pack build you'd normally use
Pack will use the directory as the application contents, so inside the container buildpacks will see the contents of that folder as /workspace.
1.mkdir multi-war
2. ./mvnw package one of your apps or a Paketo sample app
3. Copy that into the multi-war/ directory twice with different names.
4. pack build -p ./multi-war/ and include all the other options for pack build you'd normally use
Pack will use the directory as the application contents, so inside the container buildpacks will see the contents of that folder as /workspace.

By the way, do you mind if I directly contact you in slack?

Not at all. Feel free to reach on in the Paketo slack. I'm usually around there.


Pam/ch10257/update typeorm port to use latest performance

Replays the latest changes from master to this branch, and then re-applies our changes from loyaltylion/changes

since we're forked off the latest master, our version should reflect that (0.2.29-3)
Can you add some context on the DriverUtils commit? it's not explained in the PR or the commit message

since we're forked off the latest master, our version should reflect that (0.2.29-3)
Can you add some context on the DriverUtils commit? it's not explained in the PR or the commit message

I've removed that change, checking against master it wasn't, for some reason during the rebase it jumped from line 5 to end. Maybe some lint rule locally. I've moved it back to remove the change from the PR.
Have changed version


Redux in react components

Bookstore: Use Redux in React components.

In this PR, I use the Redux store to display books and also add some UI elements to the components and make them dispatch actions.

Project requirements.

First of all - make sure that you keep state immutable in reducers!
Secondly, change the default state in your books reducer from an empty array to an array with a few books. One of - -the goals is to display them in your React components.
Import Redux Provider and your store in the main component of your React app.
Connect your app to the Redux store.
Make sure that list of books displays books from Redux store.
Use useSelector to consume the state.
In your React component responsible for adding new books, add functionality for "Add new" button click:
Import Redux useDispatch.
Set the data inputs in the local React state (set title and author - NOTE: categories and comments are NOT part of this step).
Once your new book object is ready to be submitted to Redux store, dispatch a corresponding action (import Action - Creator that you created before and use it here).
In your React component responsible for removing books, add a functionality for "Remove" button click:
Import Redux useDispatch.
Dispatch a corresponding action (import Action Creator that you created before and use it here).
In your React component responsible for categories, add a functionality for "Check status" button click:
Import Redux useDispatch.
Dispatch a corresponding action (import Action Creator that you created before and use it here).
A screenshot has been added.

A new PR has been created for this project because the previous one which was marked as invalid was meant for a different branch and was mistakenly sent to this project for a review ( https://github.com/principles31/Book_Store/pull/2)

@FrederickMih, Thank you for the feedback.
I'm sorry the previous one was the wrong PR I submitted which was not meant for this project. therefore this is the original PR and a new branch for this project. The link below show was the one I submitted which was meant for a different branch ( https://github.com/principles31/Book_Store/pull/2)

@prolajumokeoni Thank you


plausible: init at 1.3.0

Motivation for this change
plausible is a simple and privacy-friendly alternative to Google Analytics based on Elixir.
cc @happysalada @lheckemann @kvz
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[x] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[ ] Added a release notes entry if the change is major or breaking
[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 124055 at 9eb694c5 run on aarch64-linux 1

1 package failed to build:

nixos-install-tools

1 package built successfully:

plausible

4 suggestions:

warning: unused-argument
Unused argument: glibcLocales.
Near pkgs/servers/web-apps/plausible/default.nix:1:47:
  |
1 | { lib, stdenv, beamPackages, fetchFromGitHub, glibcLocales, cacert
  |                                               ^

warning: unused-argument
Unused argument: stdenv.
Near pkgs/servers/web-apps/plausible/default.nix:1:8:
  |
1 | { lib, stdenv, beamPackages, fetchFromGitHub, glibcLocales, cacert
  |        ^

warning: unused-argument
Unused argument: cacert.
Near pkgs/servers/web-apps/plausible/default.nix:1:61:
  |
1 | { lib, stdenv, beamPackages, fetchFromGitHub, glibcLocales, cacert
  |                                                             ^

warning: fixup-phase
fixupPhase should not be overridden, use postFixup instead.
Near pkgs/development/beam-modules/mix-release.nix:77:3:
   |
77 |   fixupPhase = ''
   |   ^

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement. Does something look off? Please file an issue or reach out on IRC.

Thanks a lot for the reviews folks! Will work on all that next week :)

Thanks a lot for doing this!

Hi, I'm currently trying this out.
How is one supposed to set secretKeybaseFile in production?
Because DynamicUser is used, I cannot know the user ID ahead of time that will need to read that file, and I certainly don't want to put it world-readable in the nix store.
Are there any pointers I could read about how one does that?

Off the top of my head, I think LoadCredential= (see systemd.exec(5)) could be helpful for this, but I'm not sure if applying it here is trivial or not.

I'm not sure right now, but IIRC it was sufficient to set e.g. SupplementaryGroups and make the secret readable by some sort of dedicated group (which is also the default approach used by e.g. deployment.keys of nixops or sops-nix). If you're having problems with this, I can check e.g. tomorrow :)

The "best" way to do this would be to use LoadCredentials.
The current problem is that systemd is blocked at version 147 and LoadCredentials doesn't work with that version.
The other problem is to make upstream be able to read a configuration variable from a file. I've worked with upstream for that change, and it should be available in the next release.
So in summary no perfect way to do this. I haven't found a way without LoadCredentials to not have your variable readable.

@happysalada Another problem I have with DynamicUser is that I cannot figure out how to debug things well with it.
For me the plausible startup fails with
** (RuntimeError) Code: 81, e.displayText() = DB::Exception: Database `` doesn't exist (version <IP_ADDRESS>)

because in some of its calls from createdb.sh, it seems to not pass the CLICKHOUSE_DATABASE_URL=http://<IP_ADDRESS>:8123/default setting all the way through, and make ?database= requests (with empty string as the DB name), right after making two ?database=default requests.
The usual approach is to sudo -u plausible /path/to/createdb.sh, running it directly, perhaps with strace.
This seems impossible with DynamicUser, because there is no user you could sudo -u as.
So while I like the concept of DynamicUser, it seems to currently block these more fundamental debugging / sysadmin facilities.

You should be able to do something like systemd-run -p DynamicUser=yes -p StateDirectory=plausible -- your cmd. If a StateDirectory is used, the DynamicUser will be named after and then you have an environment similar to the service itself.

I love this conversation!
I originally had some problems with DynamicUser for the backup. I ended up creating another User for backup and granting all priviledges on db for it.
I don't really like having to create another user and granting all priviledges. Is there some other black magic command from systemd that has something for that?
Or do you guys also have another user for backups on production?
(I use a systemd-timer, with a simple shell script that basically dumps the db, gathers other files like uploads and the likes and borgbackup it to a remote)


Update recommended syntax for --select with unions + intersections on CLI

Docs project
Contributions

[X] I have read the contribution docs, and understand what's expected of me.

Link to the page on docs.getdbt.com requiring updates
https://docs.getdbt.com/reference/node-selection/set-operators
https://docs.getdbt.com/reference/commands/list
(I'm sure there are many more pages)
What part(s) of the page would you like to see updated?
To conform to POSIX standards, and for better readability, we should strongly encourage CLI users to quote unions/intersections passed to "multi-option" params. Unquoted may not work consistently across all operating systems, terminals, and product experiences.
This is mainly relevant for --select and --exclude.
 So instead of
$ dbt ls --select snowplow.* --output json --output-keys name resource_type description

It should be:
$ dbt ls --select snowplow.* --output json --output-keys "name resource_type description"

Additional information
internal notion doc

hey @jtcohen6 , would dbt run --select state:modified need to have "state:modified" quoted?

@mirnawong1 This is only required when there are multiple space-delimited or comma-delimited arguments being passed to --select or --exclude
So it's not strictly necessary for --select state:modified (only one argument). But --select "state:modified" works too — so we could just say "always quote" :)

sounds like a good, consistent plan. thanks for clarifying @jtcohen6 !


Fix and accelerate generated hash methods

We now create a method like we do for __init__ and hash also the class of the
instance.
Performance improvements on my notebook:
import attr

@attr.s(hash=True)
class C:
    x = attr.ib()
    y = attr.ib()
    z = attr.ib()

c = C(1, "2", 3.0)

attrs 16.3.:
➤ pyperf timeit --rigorous -s "from t import c" "hash(c)"
.........................................
Mean +- std dev: 1.81 us +- 0.06 us

attrs master:
➤ pyperf timeit --rigorous -s "from t import c" "hash(c)"
.........................................
Mean +- std dev: 474 ns +- 18 ns

This may also make @DRMacIver slightly happy.
Fixes #295
Ref #261

Re the hashing of str/floats comment:
float:
.........................................
Mean +- std dev: 454 ns +- 19 ns

str:
.........................................
Mean +- std dev: 435 ns +- 19 ns

Also the performance of hashing strings seemed more stable over multiple runs.

Great work @hynek !


infinite loop if identity-dir does not exist

Expectation: ziti-edge-tunnel exits with a non-zero errexit code when the value of --identity-dir is not a path/to/a/directory
Observation: ziti-edge-tunnel gets stuck in an infinite loop and fails to notice when the directory appears
ziti-edge-tunnel spews lines like this while stuck in the loop
[        0.980]    INFO programs/ziti-edge-tunnel/ziti-edge-tunnel.c:128 load_identities() file = (null) 0

root@kpop4:/# ziti-edge-tunnel version
v0.17.12


feat: Automatically add replaces/skips to operator csv file

Signed-off-by: Mateus Oliveira<EMAIL_ADDRESS>Describe the behavior changes introduced in this PR
Automatically add replaces/skips sections to Pelorus Operator ClusterServiceVersion file when updating/creating the  Operator.
Linked Issues
resolves #788
Testing Instructions
run rm -rf test_folder && mkdir test_folder && scripts/create_pelorus_operator -d test_folder and check if the test_folder/bundle/manifests/pelorus-operator.clusterserviceversion.yaml has the desired sections from pelorus operator tags.

/retest

Yeah, we can order the list
but I would not check here if the versions are in the correct format, this has to be done before sending them


Bubble arrow changes position

This problem seems like a bug to me. Basically, I add widgets to a GridLayout one by one. Those widgets have an attached Bubble on the right with the property arrow_pos set to "left_mid". However, once I add another widget to that GridLayout, the previous widget's arrow shifts up, as if the arrow_pos property changes to "left_top" (which is not the case, I've checked and it stays at "left_mid" all the time).
The code can be found here. On the press of a button, a new widget is added to a GridLayout

This problem seems like a bug to me. Basically, I add widgets to a GridLayout one by one. Those widgets have an attached Bubble on the right with the property arrow_pos set to "left_mid". However, once I add another widget to that GridLayout, the previous widget's arrow shifts up, as if the arrow_pos property changes to "left_top" (which is not the case, I've checked and it stays at "left_mid" all the time). The code can be found here. On the press of a button, a new widget is added to a GridLayout

Based on the changes of my PR (#7882) and after patching the test script you provided with this small patch:
`--- test_original.py	2022-05-17 21:37:51.797815319 +0200
+++ test.py	2022-05-17 21:36:56.443259703 +0200
@@ -31,6 +31,7 @@
arrow_pos: "left_mid"
pos: root.x + root.width, root.y
size: 150, 45

   BubbleContent:

''')
`
the arrow positioning should be fixed.

Closing as fixed. If the problem still occurs, please let us know.


Update open_close.py

Added battery level support for frient Entry Sensor and Entry Sensor Pro.
Proposed change

Additional information

Checklist

[ ] The changes are tested and work correctly
[ ] pre-commit checks pass / the code has been formatted using Black
[ ] Tests have been added to verify that the new code works

Black like have one space between:
-        MODELS_INFO: [(DEVELCO, "WISZB-121"),(FRIENT, "WISZB-121")],
+        MODELS_INFO: [(DEVELCO, "WISZB-121"), (FRIENT, "WISZB-121")],

I didn’t find a way to edit the code in this pull request, so i added a new one with the changes. Do I need to close this one or is it merged?

Do new edetings in your "local" git and then saving it its asking if like posting it directly or later and you can getting the pull being updated.

Do new edetings in your "local" git (danielpetrovic:patch-1) and then saving it its asking if like posting it directly or later and you can getting the pull being updated.

Thanks, I’ve pushed it again within patch-1 and it’s now running the checks.


YourFirstPR.md: "Test the changes for your application" - How to undo?

I followed https://github.com/fastlane/fastlane/blob/master/YourFirstPR.md#test-the-changes-for-your-application to use my local Fastlane checkout as the fastlane for my test project to confirm a PR I created.
Is it enough to just delete the Gemfile to undo this?

Yup! That should work, or if you simply do not run the command with the bundle exec prefix.  🌤


[WIP] add Helidon language server extension

add Helidon language server extension (is used for Helidon VSCode plugin)

Closing this PR as we agreed to create another PR based on the lsp4helidon branch.


Revisit action selection code

We should get rid of the decision tree for action selection, and just use a dictionary + compound key.
The code that we have in place is complicated and slow at startup time for small numbers of actions.
Here's a starting point for something simple with better performance: https://github.com/aspnet/Mvc/commit/e7130172d3e1c5af9f58ccfe4a20d7538b246669

This was done in preview 1 https://github.com/aspnet/Mvc/commit/e2cb8e8ac89ff91d8505967574375855bfb67112


How do I create ILoggerFactory logs with NLog?

Summary
I am attempting to add NLog to the ILoggerFactory in a web application.  I am using a cloned copy of your console sample as a guide.  I have also been reading this article.  When I added Microsoft.Framework.Logging.NLog or Microsoft.Extensions.Logging.NLog to the project.json neither package is not found.  I searched nuget.org to see if the package was there and it is not.  I decided to just use the package manager to add NLog and the config as I have done pre .Net 5.  I had to manually add the NLog.config file (not really a concern now).  My issue is that I am unable to include a reference that will allow me to use loggerFactory.AddNLog and loggerFactory.AddEventLog.
Functional Impact
I am unable to create logs.
Reproduce the Issue
Clone https://github.com/TJSoftware/LoggingTesting.git
My Question(s)
What is the correct NuGet package to use with ILoggerFactory NLog or Microsoft.Framework.Logging.NLog/Microsoft.Extensions.Logging.NLog?  If the latter, where do I find this package?
Does anyone see what else I can do to get this to work?
Code
Here is my relavant project.json code.
"dependencies": {
    ...Other Deps Here...
    "NLog": "4.2.0",
    "NLog.Config": "4.2.0"
  },
  "frameworks": {
    "dnx451": {
      "dependencies": {
      }
    }
  },

Here is the relevant Startup.cs code
loggerFactory.AddNLog(new NLog.LogFactory());
loggerFactory.AddEventLog();
//This was a long shot, but worth a try
//loggerFactory.AddProvider((ILoggerProvider)new NLog.LogFactory());

Tech Details
I am using .NET Version Manager v1.0.0-rc2-15542
I have used the runtimes
1.0.0-beta8 clr (both x64, x86) win
I am on a win 10 machine using vs 2015 enterprise.

Currently we're not releasing M.E.L.NLog package on nuget.  You should be able to clone the source and add it to your solution though.
Pre ASP.NET 5 methods for adding packages would not work, as you need to have all your references in project.json.

I agree with TJSoftware, the sample code doesn't work for me either.
I copied the files "NLogLoggerProvider.cs" and "NLogLoggerFactoryExtensions.cs" to my project and referenced NLog in my project.json:
  "frameworks": {
    "dnx451": {
      "dependencies": {
        "NLog": "4.2.1"
      }
    }
  },

The I added the following code to my Startup.cs:
 loggerFactory.AddNLog(new NLog.LogFactory());

I used the simple file logger from the samples project:
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true">
  <targets>
    <target name="logfile" xsi:type="File" fileName="log.txt"
            layout="${longdate}|${level:uppercase=true}|${logger}|${event-context:item=EventId}|${message}|${ndc}" />
  </targets>
  <rules>
    <logger name="*" minlevel="Info" writeTo="logfile" />
  </rules>
</nlog>

The application compiles, but the log file is not created.
I'm using Windows, Visual Studio 2015 and ASP.NET 5 version 1.0.0-rc1-final.

Summary
I was able to do some more tests since I first posted this, I should have updated the thread, but better late than never.  I was also able to get the sample console solution to build and run, however I do not see the file.txt created as the NLog config is setup for.  What I do see is the logs being displayed on the console printout.
Question
Should I expect a log file file.txt to be created or is this an in program logging only?  I would expect the file.txt.
Sample Console at Runtime

NLog Config
<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true">

  <targets>
    <target name="logfile"
            xsi:type="File"
            fileName="file.txt"
            layout="${longdate}|${level:uppercase=true}|${logger}|${event-context:item=EventId}|${message}|${ndc}" />
    <target name="console"
            xsi:type="ColoredConsole"
            layout="[${level:uppercase=true}:${logger}] ${message}"/>
  </targets>

  <rules>
    <logger name="*" minlevel="Info" writeTo="logfile,console" />
  </rules>
</nlog>

Yes, you should expect a log file "file.txt" to be created.
When you do the configuration in code (see my example) the log file is created in the wwwroot folder.

@makzr Yes, adding the configuration in cs code provides me with a file now.  I made the changes to the sample console project you mentioned as well as update to NLogLoggerProvider.  There was a reference to an obsolete method.  I added the IFormatProvider parameter and moved the exception to the new parameter location.  Thank you for the solution.
IFormatProvider formatProvider = new System.Globalization.CultureInfo("en-US");
var eventInfo = LogEventInfo.Create(nLogLogLevel, _logger.Name, exception, formatProvider, message);

This gives me a better understanding of why my previous code was not working.  My ConfigurationBuilder was setup like this...
var loggingConfiguration = new ConfigurationBuilder().AddJsonFile("logging.json").Build();

Because the ConfigurationBuilder is set to read its settings from logging.json, the NLog.config does not appear to be read in.  Looking at the intellisense options I see that ConfigurationBuilder has .Add(IConfigurationProvider), AddInMemoryCollection(ConfigurationBuilder, and AddJsonFile(string).

Currently we're not releasing M.E.L.NLog package on nuget. You should be able to clone the source and add it to your solution though.

@muratg You mentioned that M.E.L.NLog is not currently being release on NuGet.  Is this something that is a temporary delay or has this functionality been deprecated?

@TJSoftware the NLog provider was just a temporary sample for us to verify compatibility with existing logging systems. The readme in this repo has pointers to logging systems with official providers.


minor Fix typo

Proposed changes
Issue Number: close #xxx
Problem summary
Describe your changes.
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 34.86 seconds
load time: 454 seconds
storage size:<PHONE_NUMBER>1 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221207163527_clickbench_pr_59597.html


How to disable transitions?

Hi,
FIrst off, thanks for making this amazing theme! I'm using it in my personal website and it's awesome!
Just a little detail, is it possible to disable transitions when clicking on things such as "Posts"? The posts come from the left and stay in the center of the site.
Cheers,
-Alejandro

I thought this might be an option on the _config.yml file, but it's not. See my commit in my fork. This disables all animations.


Keep in mind utf8 strings in prefixed hashes

Here is merged master into your branch plus fixes with calculating prefixes from utf8 strings instead of encoded arrays. You can review last 2 commits after merge branch or pull changes from master into your branch and refresh.
Checklist

[ ] Change is covered by automated tests
[ ] The coding guidelines are followed
[ ] Public API has proper documentation in the Acra documentation site or has PR on documentation repository
with new changes
[ ] CHANGELOG.md is updated (in case of notable or breaking changes)
[ ] CHANGELOG_DEV.md is updated
[ ] Benchmark results are attached (if applicable)
[ ] Example projects and code samples are up-to-date (in case of API changes)

merged into #663


MINOR: Remove slf4j-log4j from kafka-streams compile dependencies

As kafka-streams is intended to be used by applications that may or may not wish to use log4j, kafka-streams itself should not have a dependency on a concrete log framework.  This change adapts the dependencies to be API-only for compile, and framework-specific for the test runtime only.
I read through the Contributing Code Guidelines and interpreted this as a trivial change that doesn't require a Jira ticket.  Please let me know if I've interpreted that wrongly.
This contribution is my original work and I license the work to the project under the project's open source license.

Unit test passed locally. LGTM and merged to both trunk and 0.10.0 branch. Thanks @mfenniak !


basic port to RV32M1 RI5CY

Summary
a basic port to RV32M1 RI5CY
Impact
Testing
the port of Nuttx has been verified on Real RV32M1-VEGA board.

Thank you @unixjet this is a great contribution. Your code in general has very good quality, only some small mistakes.
Before submitting the PR you could check the files using this command:
./tools/checkpatch.sh -f arch/risc-v/blablabla/filename.[ch]

Or simply run:
./tools/checkpatch.sh -g HEAD~...HEAD

which will report all nxstyle warning.


Locally running simulation

Hi there!
I'd like to run simulations locally without using GitHub Workflows.
$ npm install
$ npm run build

I get the following error from the above command:
ERROR in ./pkg/snippets/wasm-bindgen-rayon-9d40dbf53d170728/src/workerHelpers.worker.js 22:0-60
Module not found: Error: Can't resolve '../../../' in '/mnt/d/src/wasm-fluid-simulation/pkg/snippets/wasm-bindgen-rayon-9d40dbf53d170728/src'
Did you mean 'rust_fluid.js'?
BREAKING CHANGE: The request '../../../' failed to resolve only because it was resolved as fully specified
(probably because the origin is strict EcmaScript Module, e. g. a module with javascript mimetype, a '*.mjs' file, or a '*.js' file where the package.json contains '"type": "module"').
The extension in the request is mandatory for it to be fully specified.
Add the extension to the request.
resolve '../../../' in '/mnt/d/src/wasm-fluid-simulation/pkg/snippets/wasm-bindgen-rayon-9d40dbf53d170728/src'
  Parsed request is a directory
  using description file: /mnt/d/src/wasm-fluid-simulation/pkg/package.json (relative path: ./snippets/wasm-bindgen-rayon-9d40dbf53d170728/src)
    Field 'browser' doesn't contain a valid alias configuration
 @ ./pkg/snippets/wasm-bindgen-rayon-9d40dbf53d170728/src/workerHelpers.js 42:21-47:7
 @ ./pkg/rust_fluid.js 1:0-99 613:20-32
 @ ./index.js

webpack 5.96.1 compiled with 1 error in 1009 ms

Thanks

Hello, thanks for having an interest in this project!
I haven't figured out the root cause of the error, but a workaround I recommend is that building the repo without webpack. I'll explain the steps.

Change "build" in package.json like below.

before: "build": "cross-env RUSTUP_TOOLCHAIN=nightly wasm-pack build --target web && webpack build ./index.js --mode production -o dist --output-filename index.js && shx cp index.html dist/",
after: "build": "cross-env RUSTUP_TOOLCHAIN=nightly wasm-pack build --target web",

Change the code in Cargo.toml like below.

before: wasm-bindgen-rayon = { version = "1.2" }
after: wasm-bindgen-rayon = { version = "1.2", features = ["no-bundler"] }

Change the code in server.js like below.

before: app.use(express.static(__dirname + '/dist/'));
after: app.use(express.static(__dirname));

Remove the line import { simd } from 'wasm-feature-detect'; in index.js

This is a bit dirty workaround, but probably works.

Glad to hear that! I'll also write on README about how to run the simulation without webpack.


notificationButtons: wrong (parent) name displayed

When using notificationButtons, the name that is displayed in Home for the notification button (mapped to a switch) is the "devices" "name," e.g. "LG TV" and not that "notificationButtons" "name" e.g. "My Notification Button"

What you probably mean is not an issue with the plugin, but something that changed in ios16 for some reason. More info here: https://github.com/merdok/homebridge-webos-tv/issues/455#issuecomment-1250263091


[Android] Fix video thumbnail orientation issue

Get the rotation of the video and apply correction to the generated bitmap.

LGTM, thank you! 👍