Add support for secure text entry in rumps.Window

Added an import of NSSecureTextField from AppKit and a bool argument
(‘secure’) to rumps.Window that will use the NSSecureTextField in place
of the standard NSTextField. Passing ‘secure=True’ will provide a text
box that hides the user’s input (use case: password prompt).
rumps.Window using NSSecureTextField:

Tested on 10.9 and 10.10.

:+1:  let's get this merged!

+1!

awesome! +1

https://github.com/jaredks/rumps/pull/95


.NET 4.5 compatibility

can this work on .NET 4.5 ?

Added support for .NET Standard 1.1 with 0.0.3 (78df9e09497be7b73ae2002716c30dd9570a6082), which works with .NET 4.5.


[CHORE] adding semver dep

Need dep for semver

This was for testing, seems this incorrectly was sent to Upstream


[FLINK-17976][docs][k8s/docker] Improvements about custom docker images

What is the purpose of the change
While testing the native Kubernetes integration (in particular when trying to access Google's GCS file system), I had issues building a custom docker image for that purpose.
This PR tries to give users some clarification and tools for the task.

Thanks a lot for creating this PR to enrich the document. I will help the users to start quickly and save their time.
Changes look good to me. +1 for merging.
I will create a follow-up PR to translate the native K8s changes into Chinese.

Thank you for your review.


Introduce the concept of root properties

Related to #340

@msaraiva

If you want to do it in the scope of this PR, it's fine. If not, it's fine too :)

I'll do this in a new PR :)


Add Buy API

Here is new api: https://go.developer.ebay.com/api-documentation#new_buy
Would be great to add it in your sdk

I'm currently working on adding this to the SDK. Looking at getting a release out in January.


Add Gradle property for logging

Context
Fixes #1919
Contributor Checklist

[x] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
[x] Provide unit tests (under <subproject>/src/test) to verify logic
[x] Update User Guide, DSL Reference, and Javadoc for public-facing changes
[x] Ensure that tests pass locally: ./gradlew quickCheck <impacted-subproject>:check

Gradle Core Team Checklist

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation including proper use of @since and @Incubating annotations for all public APIs

@lacasseio, I made the changes you suggested.  Please take a quick peak to see if you're satisfied.  I also kicked off a new partial coverage build with my changes.

Why are we doing this?

@adammurdoch The goal is to make it trivial for users to get back to the 3.x logging behavior if they really prefer to see all of the tasks. Otherwise, log level must be specified by the client on every invocation.

Why are we not using a command-line option as we do for all the other logging configuration?

Ah, nevermind. I missed that it's to make the change persistent


Thanks for this great tool by the way.

If you're referring to something like this, the solid line is the first parent of a merge commit, and the dashed line is the second parent.


fix: Allow quota project to be used in combination with null credentials

Credentials may be null, e.g. when connecting to an emulator. This fix makes it possible to use null credentials in combination with setting quota project id, something that may be useful in testing.
Fixes #1687 ☕

Thanks @irock for the PR! I ran a sample locally and I believe I was able to reproduce the error (by setting the quotaProjectId
and using NoCredentialsProvider):
Caused by: io.grpc.StatusRuntimeException: UNAUTHENTICATED: Failed computing credential metadata
	at io.grpc.Status.asRuntimeException(Status.java:539)
	... 17 more
Caused by: java.lang.NullPointerException: Cannot invoke "com.google.auth.Credentials.getRequestMetadata(java.net.URI)" because "this.wrappedCredentials" is null
	at com.google.api.gax.rpc.internal.QuotaProjectIdHidingCredentials.getRequestMetadata(QuotaProjectIdHidingCredentials.java:64)
	at com.google.auth.Credentials.blockingGetToCallback(Credentials.java:112)
	at com.google.auth.Credentials$1.run(Credentials.java:98)
	... 3 more

Similar error exists for httpjson as well.
Is there a specific sample or reference that you were using (or is the a specific case for your tests)? Just trying to figure out the use case for NoCredentialsProvider + setting the QuotaProjectId.

Thanks @irock for the PR! I ran a sample locally and I believe I was able to reproduce the error (by setting the quotaProjectId and using NoCredentialsProvider):
Caused by: io.grpc.StatusRuntimeException: UNAUTHENTICATED: Failed computing credential metadata
	at io.grpc.Status.asRuntimeException(Status.java:539)
	... 17 more
Caused by: java.lang.NullPointerException: Cannot invoke "com.google.auth.Credentials.getRequestMetadata(java.net.URI)" because "this.wrappedCredentials" is null
	at com.google.api.gax.rpc.internal.QuotaProjectIdHidingCredentials.getRequestMetadata(QuotaProjectIdHidingCredentials.java:64)
	at com.google.auth.Credentials.blockingGetToCallback(Credentials.java:112)
	at com.google.auth.Credentials$1.run(Credentials.java:98)
	... 3 more

Similar error exists for httpjson as well.
Is there a specific sample or reference that you were using (or is the a specific case for your tests)? Just trying to figure out the use case for NoCredentialsProvider + setting the QuotaProjectId.

We're using QuotaProjectId internally at Spotify to make sure the correct GCP project is correctly attributed when running Pub/Sub workloads in multi-tenant kubernetes clusters.
The combination of QuotaProjectId + NoCredentialsProvider appears during testing, e.g. when we configure a Pub/Sub consumer to connect to a local emulator.
Btw, one workaround we have found is to use a different case for the header key, e.g. X-Goog-User-Project instead of the lower case x-goog-user-project. In practice this attributes the quota correctly, but bypasses the use of QuotaProjectIdHidingCredentials.

Thanks for the info. I haven't seen the combo of QuotaProjectId + NoCredentialsProvider before and was kind of curious if this was something certain services were suggesting to do. Makes sense that this appeared during testing.
I do think that this is an odd behavior and that this change shouldn't have any impact. Null credentials is not going to have any conflicting quota project ids.
Looping in @blakeli0 for a second opinion.

Thanks @lqiu96 for the initial review!

The combination of QuotaProjectId + NoCredentialsProvider appears during testing, e.g. when we configure a Pub/Sub consumer to connect to a local emulator.

@irock I'm not sure I understand the usefulness of this test. Why do you need to set QuotaProjectId in a local emulator testing? Is it being verified somewhere in the test? Your workaround makes sense because that is effectively not setting QuotaProjectId, if the workaround is acceptable, I would suggest not to set x-goog-user-project header at all in your tests.
In general, adding test only code is not ideal, and this change also has some side effect. e.g. If someone sets QuotaProjectId but couldn't get credentials in production, the request is now failing much later on the server side instead of client side.

Thanks @lqiu96 for the initial review!

The combination of QuotaProjectId + NoCredentialsProvider appears during testing, e.g. when we configure a Pub/Sub consumer to connect to a local emulator.

@irock I'm not sure I understand the usefulness of this test. Why do you need to set QuotaProjectId in a local emulator testing? Is it being verified somewhere in the test?

We are not testing the quota project id specifically, as we trust the library to do the right thing. Rather, we want our tests to be opaque to the fact that quota project id is set. As you can imagine, we could technically have tests explicitly disabling the quota project id, but that seems like a leaky abstraction.

Your workaround makes sense because that is effectively not setting QuotaProjectId, if the workaround is acceptable, I would suggest not to set x-goog-user-project header at all in your tests.

As far as I can tell, our workaround is effectively setting the quota project id in requests to Pub/Sub. Indeed, the requests will fail unless the service has permissions to consumer quota from the project in question. The code in the library is checking for lower case only, but it seems like the server side is case agnostic.

In general, adding test only code is not ideal, and this change also has some side effect. e.g. If someone sets QuotaProjectId but couldn't get credentials in production, the request is now failing much later on the server side instead of client side.

As I understand it, the intention of QuotaProjectIdHidingCredentials is to hide any attempts by the credentials to set the quota project id. If credentials is null, it is impossible for this to happen, and there is no need for wrapping the credentials in the first place.
I think if you want the code here to protect users from configuring the library incorrectly, it would be better to check that explicitly. Indeed, NoCredentialsProvider is a supported use, and the rest of the code in this class does handle this appropriately.

Rather, we want our tests to be opaque to the fact that quota project id is set. As you can imagine, we could technically have tests explicitly disabling the quota project id, but that seems like a leaky abstraction

I don't think I agree that it is a leaky abstraction, the test setups are supposed to be different if you are testing locally. For example, as you mentioned, you have to initialize the client with NoCredentialsProvider, I don't see much difference between setting NoCredentialsProvider and not setting quota project id. Also how did you set quota project id in the tests? It should not be set by default, but explicitly disabling the quota project id makes me guessing that you have a generic test setup that is always setting it?

I think if you want the code here to protect users from configuring the library incorrectly, it would be better to check that explicitly. Indeed, NoCredentialsProvider is a supported use, and the rest of the code in this class does handle this appropriately

Yes I agree it would be better to check it explicitly. I'm using this as an example to show that this is technically a behavior breaking change, as we may have customers that are dependent on this behavior(even if the behavior may not be ideal), e.g. Some customers may have a test verifying NullPointerException for the combination of QuotaProjectId + NoCredentialsProvider, this change would break that test now. I would probably go with your approach if we are implementing QuotaProjectId from scratch but I would be hesitate to make the change now. Also NoCredentialsProvider is a supported use case but maybe it should not be used in combination with QuotaProjectId.
In short, thanks for finding this issue and I think it's a miss on our side, we should've made it clear that whether QuotaProjectId can work together with NoCredentialsProvider or not when we implemented QuotaProjectId. I'll dig a little more and see the full impact of the change, but in the mean time, I would suggest to not setting QuotaProjectId in the tests.

Rather, we want our tests to be opaque to the fact that quota project id is set. As you can imagine, we could technically have tests explicitly disabling the quota project id, but that seems like a leaky abstraction

I don't think I agree that it is a leaky abstraction, the test setups are supposed to be different if you are testing locally. For example, as you mentioned, you have to initialize the client with NoCredentialsProvider, I don't see much difference between setting NoCredentialsProvider and not setting quota project id. Also how did you set quota project id in the tests? It should not be set by default, but explicitly disabling the quota project id makes me guessing that you have a generic test setup that is always setting it?

To clarify how this works in more detail, our test code is written to diverge from production settings as little as possible.
For example, the production code may have configuration like so:
# service.conf
pubsub {
  subscriber {
    project-id: my-gcp-project-id
    subscription-id: my-subscription-id
    quota-project-id: my-gcp-project-id
  }
}

Dependencies for the service are discovered during boot, through service discovery mechanisms such as DNS and other means. Our test environments mimics production here, using mock test-containers and network configuration to tie the service to its dependencies without the need for the service to have custom test code.
For Pub/Sub, that discovery mechanism does not work, and we need to specifically configure the service to connect to the Pub/Sub emulator host/port. Furthermore, as the emulator does not support credentials, we need to configure the service to connect using no credentials. From an end developer user experience point of view, this is quite cumbersome as it is.
Clearing quota project id is another emulator specific setting that developers need to be aware of when they set up tests.
So in summary, in order to test a Pub/Sub integration with an emulator, developers need to know not only that they should connect the service to the emulator explicitly through host/port configuration (e.g. setting up a custom transport channel), but also that the emulator does not support credentials, and that the library will malfunction if one sets the quota project id.
This is what I mean when I say that it's a leaky abstraction. The emulator is supposed to abstract away the Pub/Sub service so that developers can confidently test their code. But the difference in functionality is leaking to users.

I think if you want the code here to protect users from configuring the library incorrectly, it would be better to check that explicitly. Indeed, NoCredentialsProvider is a supported use, and the rest of the code in this class does handle this appropriately

Yes I agree it would be better to check it explicitly. I'm using this as an example to show that this is technically a behavior breaking change, as we may have customers that are dependent on this behavior(even if the behavior may not be ideal), e.g. Some customers may have a test verifying NullPointerException for the combination of QuotaProjectId + NoCredentialsProvider, this change would break that test now. I would probably go with your approach if we are implementing QuotaProjectId from scratch but I would be hesitate to make the change now. Also NoCredentialsProvider is a supported use case but maybe it should not be used in combination with QuotaProjectId.

This seems like a very hypotethical use case. The fact is that using QuotaProjectId plus NoCredentialsProvider does not work today, and this PR fixes this.
Yes, alluding to Hyrum's Law, if someone has written a test that confirms that the library breaks if this combination is used, then that test will not pass after this change. However, couldn't the same be said about any bug?

In short, thanks for finding this issue and I think it's a miss on our side, we should've made it clear that whether QuotaProjectId can work together with NoCredentialsProvider or not when we implemented QuotaProjectId. I'll dig a little more and see the full impact of the change, but in the mean time, I would suggest to not setting QuotaProjectId in the tests.

If you do not accept this change, would you accept a PR that explicitly throws if QuotaProjectId is used together with NoCredentialsProvider? I think that would break more tests than this PR.

This is what I mean when I say that it's a leaky abstraction. The emulator is supposed to abstract away the Pub/Sub service so that developers can confidently test their code. But the difference in functionality is leaking to users.

I totally understand the frustration of having to set up things differently in local testing, especially when these things are added on top of emulators, we suffer the same in our own local testing. Unfortunately our team does not own the emulators, if you can file a request(preferably through Support) with what exactly you want to improve on the emulators side, I would be more than happy to help you as much as I can internally.

This seems like a very hypotethical use case. The fact is that using QuotaProjectId plus NoCredentialsProvider does not work today, and this PR fixes this.
Yes, alluding to Hyrum's Law, if someone has written a test that confirms that the library breaks if this combination is used, then that test will not pass after this change. However, couldn't the same be said about any bug?

I don't disagree that this is a very unlikely use case, and you could say the same for any bug. But since the impact is huge with every little change in this repo, we have been very careful in fixing anything/making any behavior changes in this repo. Usually how we decide if we want to fix a bug is that:

Does this affect production? In this case, no.
Do we have a workaround? In this case, yes.

So that makes the fix of this bug low benefit, and high risk(probably could be lower but need more investigation to confirm).

If you do not accept this change, would you accept a PR that explicitly throws if QuotaProjectId is used together with NoCredentialsProvider as it is not supported? I think that would break more tests than this PR.

I would accept neither as of now, but I want this in as much as you want since it can definitely improve customer experience in testing. So as I mentioned previously, I'll dig more and see if we can determine the risk.

This is what I mean when I say that it's a leaky abstraction. The emulator is supposed to abstract away the Pub/Sub service so that developers can confidently test their code. But the difference in functionality is leaking to users.

I totally understand the frustration of having to set up things differently in local testing, especially when these things are added on top of emulators, we suffer the same in our own local testing. Unfortunately our team does not own the emulators, if you can file a request(preferably through Support) with what exactly you want to improve on the emulators side, I would be more than happy to help you as much as I can internally.

Thanks, we might do that.

This seems like a very hypotethical use case. The fact is that using QuotaProjectId plus NoCredentialsProvider does not work today, and this PR fixes this.
Yes, alluding to Hyrum's Law, if someone has written a test that confirms that the library breaks if this combination is used, then that test will not pass after this change. However, couldn't the same be said about any bug?

I don't disagree that this is a very unlikely use case, and you could say the same for any bug. But since the impact is huge with every little change in this repo, we have been very careful in fixing anything/making any behavior changes in this repo. Usually how we decide if we want to fix a bug is that:
1. Does this affect production? In this case, no.

2. Do we have a workaround? In this case, yes.

So that makes the fix of this bug low benefit, and high risk(probably could be lower but need more investigation to confirm).

Thanks for clarifying. I understand I don't have all the context required to assess the risk of this change. From my perspective the implicit risk of keeping this behavior is not to be disregarded either, as the library malfunctions in a quite indirect way.

If you do not accept this change, would you accept a PR that explicitly throws if QuotaProjectId is used together with NoCredentialsProvider as it is not supported? I think that would break more tests than this PR.

I would accept neither as of now, but I want this in as much as you want since it can definitely improve customer experience in testing. So as I mentioned previously, I'll dig more and see if we can determine the risk.

I appreciate that!

@irock This PR is now merged and expected to be released in the next two weeks.

@irock This PR is now merged and expected to be released in the next two weeks.

Thank you! 🙌


Error about rootful should only show on mac + windows

Is your enhancement related to a problem? Please describe
When running the container, podman machine is for mac / windows. make sure running rootful is ONLY checked for mac / windows
Describe the solution you'd like
only check on mac / windows.
Describe alternatives you've considered
No response
Additional context
No response

This was completed as part of PR #84.


Mostly blank error message

I'm running prebuild on Windows and scratching my head more than usual.
PS C:\Users\Administrator\zmq-prebuilt> prebuild --all
prebuild info begin Prebuild version 4.1.0
prebuild info build Preparing to prebuild<EMAIL_ADDRESS>for v0.10.42 on win32-x64 using node-gyp
prebuild http GET https://nodejs.org/dist/v0.10.42/node-v0.10.42-headers.tar.gz
prebuild http 200 https://nodejs.org/dist/v0.10.42/node-v0.10.42-headers.tar.gz
prebuild WARN install got an error, rolling back install
prebuild ERR! install error
prebuild ERR! stack Error: unexpected end of file
prebuild ERR! stack     at Zlib._handle.onerror (zlib.js:363:17)
prebuild ERR! not ok
prebuild ERR! build unexpected end of file

Any idea how to extract more logs out of this? prebuild --compile works fine

This is the same issue as https://github.com/nodejs/node-gyp/issues/693 IMO. When fetching the node files, there are random failures on the last chunk. It succeeds perhaps 10-20% of the time. Other times you'll get checksum errors, and this error if the code continues to try to unpack the archive.
It works with prebuild --compile because you're not fetching anything.
You can reproduce using node-gyp install and the simple download script from @klemmster. The fault is presumably in node itself. HTTP fetching should not be failing like this.

so very right, thanks for linking the node-gyp issue
I think I can close this as an upstream issue to be solved.


sls deploy failed: failed to fetch routes

The example fails with
endpoints (api-gw):
**failed to fetch routes**
endpoints (web actions):
**no web actions deployed**

I have same issue on console

https://github.com/serverless/serverless-openwhisk/issues/103
Refer to this. After I configure this, it's OK

Exporting an environment variable OW_APIGW_ACCESS_TOKEN with the value of APIGW_ACCESS_TOKEN found in .wskprops property file fixes the problem.


Test blockchain queries and develop v1 onchain user metrics

Forgive me, just pasting same guidance:
Could you either link to the work / close issue,
or fix the status and move to appropriate sprint?


panic when creating a list using bool or NA values

When sending a command to create a list I'm getting a panic: runtime error: index out of range with certain combinations of values.  What I've observed is the following.

Creating a list of strings, ints, and floats in any combination works.
Ex: list(int=1,string='s',float=0.5)

If the list has a bool or NA as the last value, the correct result is returned but there is a Warning: Error whilst constructing vector: Abruptly reached end of buffer outputted.
Ex: list(int=1,string='s',float=0.5,bool=TRUE)
Ex: list(var=NA)

If the list contains a bool or NA value with anything else following it, a panic happens.
Ex: list(int=1,string='s',float=0.5,bool=TRUE,anything='this causes a panic')
Ex: list(var1=NA,var2=1)

Here is the full stack trace for the panic:
panic: runtime error: index out of range

goroutine 1 [running]:
roger/sexp.getLength(0xc820431484, 0x38, 0x38, 0x29, 0x1, 0x420460, 0x0, 0x0)
	roger/sexp/factory.go:25 +0x12f
roger/sexp.parseReturningOffset(0xc820431484, 0x38, 0x38, 0x29, 0x0, 0x0, 0x0, 0x0, 0x0)
	roger/sexp/factory.go:35 +0xa0
roger/sexp.parseVector(0x437840, 0xc820436960, 0xc820431484, 0x38, 0x38, 0x29, 0x38, 0x0, 0x0, 0x0, ...)
	roger/sexp/xt-vector.go:37 +0xba
roger/sexp.parseReturningOffset(0xc820431484, 0x38, 0x38, 0x20, 0x0, 0x0, 0x8591d, 0x0, 0x0)
	roger/sexp/factory.go:80 +0x752
roger/sexp.Parse(0xc820431484, 0x38, 0x38, 0x0, 0x0, 0x0, 0x0, 0x0)
	roger/sexp/factory.go:13 +0x61
roger.(*packet).GetResultObject(0xc820436930, 0x0, 0x0, 0x0, 0x0)
	roger/packet.go:77 +0x31e

Thanks for the detailed issue!
I will try to look into this issue this weekend. I fear the list parsing is not correct and this probably relates to #24.

Thanks. Let me know if you need any more info from me.

Incorrectly closed by my previous commit.  Reopening, as NA handling still needs work.

Any word on NA? I am interested in using it, but running into this issue.

I have began working on support for NAs in lists, however it is tricky to do in a backwards compatible manner. Hopefully I will get time to finish it off shortly.
I am very open to pull requests for this


[MINOR][SQL]Change  ThreadLocal.withInitial  to Scala lambda syntax

What changes were proposed in this pull request?
Currently, Scala  has updated to Scala 2.12.8 ,  so  we can change this to Scala lambda syntax
How was this patch tested?
Existing tests.
And Manual testing:
== Physical Plan ==
*(3) HashAggregate(keys=[attribute#237L], functions=[sum(cnt#227L)])
+- Exchange hashpartitioning(attribute#237L, 5)
   +- *(2) HashAggregate(keys=[attribute#237L], functions=[partial_sum(cnt#227L)])
      +- *(2) HashAggregate(keys=[nested#223.attribute#243L], functions=[count(1)])
         +- Exchange hashpartitioning(nested#223.attribute#243L, 5)
            +- *(1) HashAggregate(keys=[nested#223.attribute AS nested#223.attribute#243L], functions=[partial_count(1)])
               +- *(1) Project [nested#223]
                  +- *(1) Scan ExistingRDD[nested#223,value#224L]

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/testing-k8s-prb-make-spark-distribution-unified/5998/
Test PASSed.

Test build #100003 has started for PR 23295 at commit 361ed5c.

Test build #100003 has finished for PR 23295 at commit 361ed5c.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

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/100003/
Test FAILed.

Test build #100014 has finished for PR 23295 at commit 361ed5c.

This patch fails SparkR unit tests.
This patch merges cleanly.
This patch adds no public classes.

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/100014/
Test FAILed.

Test build #100059 has started for PR 23295 at commit 361ed5c.

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/testing-k8s-prb-make-spark-distribution-unified/6047/
Test PASSed.

Test build #100059 has finished for PR 23295 at commit 361ed5c.

This patch fails SparkR unit tests.
This patch merges cleanly.
This patch adds no public classes.

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/100059/
Test FAILed.

retest this please

Test build #100081 has started for PR 23295 at commit 361ed5c.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/6068/
Test PASSed.

Merged build finished. Test PASSed.

Test build #100081 has finished for PR 23295 at commit 361ed5c.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

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/100081/
Test FAILed.

We still build against 2.11 too. Unless you have built with 2.11 and this works, we can't merge this.

The ThreadLocal.withInitial  lambda syntax is supported in java1.8, and this is already used in ReadAheadInputStream class.

This isn't Java code though. It may well work, but it needs to be tested against 2.11. The pull request builder doesn't test this. Have you? I remember some odd issues with Scala's willingness to match closures to single-arg function args, and given this comment, I think we need to be sure first.

I see ,I have a mistake, this is scala code, thanks @srowen,  I will close this PR


xcode7.1下PacketNetwork.swift  has many errors???

I cannot resolve it ... So can you help me???

My guess is you are using a newer version of Swift. I haven't touched this project 8 months, and Swift has updated a couple times since then.
The soonest I could look at this is this weekend.

Thank you for you reply,and i will also learn something new. I will persistent attend you .Looking forward to your update.


Investigate being able to drink/eat/and get while sitting lol its a weird command

Probably hinting at a newepic. Another perspecive on this is  fail messages reported to players while e.g. sleeping


haskellPackages.containers-unicode-symbols, haskellPackages.numerals-base: unbreak

Description of changes

Override too restrictive bound on containers in haskellPackages.containers-unicode-symbols
First step to start on https://github.com/NixOS/nixpkgs/issues/287972
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Thank you!
If you care about those packages staying unbroken you might consider entering yourself as a maintainer.


[Feature Request] Recommendations to friends and knowing when media is completely consumed

Description
Managing content suggestions and retirements within my family library is a chore. Suggesting shows to watch and tracking if they are completely viewed, in progress, abandoned or blocked by age restrictions is more effort than it should be.
Being able to suggest a show to someone via JellySeer rather than hollering to go read a synopsis whilst you wait would save a lot of effort.
Having that user then be able to tag their interest level, especially if they don't want to watch it, solves the dilemma that watch status alone cannot determine if media has been consumed i.e. "have watched the entire show", "will never watch a show" and "are not old enough to watch a show" are all logically the same, the show is completed for this user.
Desired Behavior

Be able to suggest a media to someone via JellySeer
Be able to track interest level of suggestions
Be able to summarise status for my family to make deletion and archival decisions

Additional Context
I realise this is possibly out of scope however JellySeer is in a unique "overwatch" position to do this especially since the concept of recommendations already exists.
Code of Conduct

[X] I agree to follow Overseerr's Code of Conduct

Do you mean kind of like a upvote system?

Sorry for the wall of words. :)
Whilst trying to think about how to answer this other than just agree that it is a sort of "upvote system" I thought a real world example would help set the scene.
I manage the content for my close family using Emby to offer a single contiguous interface and some semblance of privacy. No one can host all things for all time so I need to make informed decisions on what can be archived or deleted and when.
Data comes into the system via Jellyseerr requests and other normal methods. This is where it starts to get interesting.
If a user has requested something then I know it is wanted, however I have no idea if the rest of my family are interested in it. This means I never have complete information to make any definitive archival or deletion decisions unless I just guess or actually talk to everyone for each specific bit of content.
The traditional approach to this is to use watch status as an indicator of completion but it is very rare with a 70 year difference in age range content is ever completely ticked watched. It gets even more complicated when some of the content cannot be consumed as the kids are too young for it or maybe someone wants to watch the content but not start until the season is complete.
There are many more variations in here such as someone starts one episode of a show to see if they like it and this partial watch state could either mean they loved it and are waiting for a good time to watch or they hated it and will never watch.
This is the crux of the problem and the suggestion. Jellyseerr already has the concept of "recommended" but it is single user algorithm driven. Jellyseerr is also in a unique position where it "stands above" the media library and could help the system admin collect and summarise information to help in the archival and deletion decision process.
So for example:

"The system admin wants to know if you are plan to watch this Season"
"User X has recommended this show just for you, are you going to watch it? Now-Later-Never-Dont know yet"
"User X has recommended this show for the entire family"
"Did you like this show? Yes-Will never watch"
"The system will remove this content in XX days. Request deletion delay yes/no"

I have other ideas for this but they are all variations on the theme, Jellyseerr through automation and direct user interactions summarising content status.


Line height for code

Line height added for code itself. I hope it is the right place.

Much better indeed.
before:

after:


Does this repo have a beta NuGet package for ASP.NET v5 MVC 6 (vNext)?

I'm trying to build an MVC 6 class library built over DNX, and it doesn't look like one of this project's frameworks on the NuGet package.
Am I wrong?

Figured it out, I had to add the frameworks section in my DLL.


Handling of @Id and @Version fields in AutoCrud could be improved

Describe the bug
When you have a JPA entity with a field annotated with @Id or @Version and you use this entity in the AutoCrud component, you likely won't be able to submit the form of the AutoCrud component. You can fill the form and press submit, but nothing will happen, and you won't see any errors in the frontend or backend.
Hilla validates these fields already on the client, but the error is never shown because AutoCrud / AutoForm hide fields for id and version automatically. So there are client-side validation errors, but they are not visible. The values for id and version fields are generated only on the server after saving an entity.
A workaround is to add the @com.vaadin.hilla.Nullable annotation to the id and/or version field of the JPA entity, but this feels strange. From a developer perspective, I want this fields to be not empty nor null, and I know, that JPA will take care of this.
Expected-behavior
Using the annotations @Id and @Version is quite common. As a developer, I want to use entities with these annotations in the AutoCrud component with a good developer experience. This could mean:

Getting an error/warning when the validation of the hidden id and/or version field in the AutoCrud components fails. This could be a console.error or a notification or a popup/popover.
AutoCrud could skip validation for fields that are hidden per default.

Reproduction

Create a new Hilla project using start.vaadin.com or Vaadin CLI
Add an entity with id and/or version field and @Id and/or @Version annotations
Create a JpaRepository and CrudRepositoryService for that entity
Create a view, add the AutoCrud component to that view and configure the component to use the generated model and service of that entity.
Try to add a new item with the form component of the AutoCrud component

System Info
Vaadin 24.5.0.beta6

Origin: https://vaadin.com/forum/t/hilla-autocruds-submmit-button-wont-persist-data-on-database/166588

See #2217 specifically about the errors from hidden fields. Besides that, we could assume @Nullable for such @Id and @Version fields, allowing the value to be undefined on the client side.

I just realized that I was able to use entities with id and/or version fields together with AutoCrud and AutoForm in a previous app using Vaadin 24.4. Did this behaviour change on purpose?

I think I need to add some more context. I detected a typo in my example code
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long id;

For some reason I don't understand, I used long instead of Long which results in the behaviour described above.
Using private long id means that I was not able to submit a AutoCrud or AutoForm component, because Hilla's client-side validation prevents the form from being submitted to the backend.
Using private Long id works just fine, which means that I was able to submit a AutoCrud or AutoForm component.


Streamline log

The logfile grows around 1M/hour (on my instance) with a large part of the messages being this INFO "Bus:Handling". I propose changing the message to debug message to reduce the file size and to help streamline reading of logs.
Description:
Related issue (if applicable): fixes #
Pull request in home-assistant.github.io with documentation (if applicable): home-assistant/home-assistant.github.io#<home-assistant.github.io PR number goes here>
Example entry for configuration.yaml (if applicable):

Checklist:

[x] The code change is tested and works locally.
[x] Local tests pass with tox. Your PR cannot be merged unless tests pass

If user exposed functionality or configuration variables are added/changed:

[x] Documentation added/updated in home-assistant.github.io

If the code communicates with devices, web services, or third-party tools:

[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[x] Tests have been added to verify that the new code works.

I'll just close this PR and create a new one. I created the PR with a
simple edit on github. I don't know how to add another file to the PR using
Github. Not sure it's even possible.
On Tue, 28 Aug 2018 at 03:25, Paulus Schoutsen<EMAIL_ADDRESS>wrote:

I think I agree with this. What do others think?
Tests need fixing btw.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/16221#issuecomment-416479018,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AC6xoE0sWxlAuH5E3r_CSDaxjuSNEXtcks5uVPB3gaJpZM4WN0mG
.

@gwww You can add files to your branch gwww:patch-1.

Can you add files right in github website? That's how I created this patch.

Yes, you can upload files via the website or work on your fork using any git editor you prefer.

I agree this will be a good change. Test can be intimidating; I have spent more time on tests than actual code! But without tests you don't know when you break things so they are super valuable, especially for such a big project.
Couple cliff notes, you really do need to dig into creating a git repo and doing some testing locally, it's a bit of work but worth it. Then you can edit things and test locally using py test. For instance I duplicated your change and ran this in the directory to run the test.
pytest tests/components/zwave/test_init.py
Got the same error as jenkins
 tests/components/zwave/test_init.py ✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓✓                                                                                64% ██████▍

――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――― TestZWaveServices.test_print_node ―――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――

self = <tests.components.zwave.test_init.TestZWaveServices testMethod=test_print_node>

    def test_print_node(self):
        """Test zwave print_node_parameter service."""
        node = MockNode(node_id=14)

        self.zwave_network.nodes = {14: node}

        with self.assertLogs(level='INFO') as mock_logger:
            self.hass.services.call('zwave', 'print_node', {
                const.ATTR_NODE_ID: 14
            })
            self.hass.block_till_done()

>           self.assertIn("FOUND NODE ", mock_logger.output[1])
E           IndexError: list index out of range

Essentially this test is creating a mock node 14 and looking in the log file for the 'FOUND NODE' message. It is creating a log with a level of 'INFO' and checking that log. So you can probably guess why it broke, right? :-)
TL; DR; Change 'INFO' to 'DEBUG' on line 1183 in test/components/zwave/test_init.py

Ack, I see you did submit the PR in another request. It is generally better to work off the same one to preserve comments.
Also as the owner of the PR you can close it yourself.


Cannot Set Brightness via Script/Automation

Describe the bug
Setting the brightness via the included service fails.
To Reproduce
Steps to reproduce the behavior:

Create a script or automation
Add "Call Service" action
Select "Philips Hue Play HDMI Sync Box: Set brightness"
Select brightness in UI or set via YAML

Only 0 and 1 can be selected as values and setting values via YAML does not work either.
Expected behavior
Brightness value of Hue Sync Box updated.
Environment

Home Assistant Core version: core-2021.11.0
Home Assistant operating environment (OS/Container/Supervised/Core): OS
Huesyncbox integration version: 1.14.0

Should be fixed in v1.15.0.

Confirmed. Fixed!
Thank you!!!


Transform drops non-existing files that will later exist

We're seeing an unfortunate interaction between the plugin and Spring Boot. We first saw this problem with dependency tasks on resolution failure, but it turns out this can affect transforms too:

https://github.com/spring-projects/spring-boot/issues/30586
https://github.com/spring-projects/spring-boot/issues/31216

This behaviour causes files in a configuration to be resolved during metadata resolution. If one of those dependencies comes from a sub-project that hasn't built yet, the transform is triggered for a non-existent file.
 We may have library projects internally that'll use javax and won't get transformed for their own application, but we can't do anything until the upstream issue is fixed.
Once it's fixed, we should reinstate this logic:
https://github.com/nebula-plugins/gradle-jakartaee-migration-plugin/commit/64295aa1f17d63669142b0bd52c5e35de0ea6d98

Looks like we'll need to write an empty file instead, Gradle doesn't like a missing file coming off a transform.

0.6.5 at least avoids this. It does leave those files untransformed however, so there's still a risk of missing a javax reference in a library subproject.

Throwing the FNFE in 0.7.0 is the correct way to handle this. If you're impacted, avoid configuring the bootJar task until the upstream issue is fixed.


Some unsafe code in arrow is unsound or not very well documented.

Hi all,
while going through the code in arrow, I spotted a few places in which the usage of unsafe code is unsound, and a few in which I could not determine whether it was or not.
I do not believe that the issues I found could cause problems today, but I prepared a PR nonetheless that fixes the unsound cases I could find, improves documentation in the cases in which I could figure out why the code is indeed sound, and leaves a FIXME comment for the remaining cases that were beyond my ability to figure out :-)
I hope this helps!

Thank you @veluca93 @

Thank you for this, I've changed this to be labeled as an enhancement as I don't believe there is unsoundness in user-facing APIs and I'd like to avoid causing undue wailing and gnashing of teeth.
As an aside thank you for adopting a constructive tone, its unfortunately not a given when it comes to areas such as this


[Issue]: Team status - add mailto link

Expected State
In the team status section on the grant details page, for any applied status, underneath the text describing who assigned the status, the next line will show the email of the user who applied the status - this will show as a mailto: link so users can easily send a message if desired
Design: https://www.figma.com/file/yQx55VTr5awPYClHIJCz8y/Grant-Details?type=design&node-id=2092-16847&mode=dev
Implementation Plan
Update the part of the GrantDetails.vue view that is responsible for rendering the text of

User Name updated Agency Name team status to Interested Code Name

Modify the HTML template that renders the User Name portion of the above so that the name of the user is hyperlinked to the email address (i.e. mailto: scheme) provided by agency.user_email in the current iteration of the wrapping
 loop.
The result might render the above example like the following:

User Name updated Agency Name team status to Interested Code Name

Relevant Code Snippets

      {{ agency.user_name }} updated
      {{ agency.agency_name }} team status to
      {{ agency.interested_code_name }}

{{ agency.user_name }} updated

@TylerHendrickson can you please add implementation details for this one then move to ready? this is the other item that was not completed for #2559

@ClaireValdivia Implementation details added.

looks great. may be good to open in a new tab, and can create an issue for this


[445822.894246] docker0: port 1(veth8daed26) entered disabled state
[445822.899682] device veth8daed26 left promiscuous mode
[445822.899690] docker0: port 1(veth8daed26) entered disabled state
[445823.152025] docker0: port 1(veth7bea3cb) entered blocking state
[445823.152028] docker0: port 1(veth7bea3cb) entered disabled state
[445823.152407] device veth7bea3cb entered promiscuous mode
[445823.153781] docker0: port 1(veth7bea3cb) entered blocking state
[445823.153783] docker0: port 1(veth7bea3cb) entered forwarding state
[445823.398782] eth0: renamed from veth49e9ab9
[445823.436289] IPv6: ADDRCONF(NETDEV_CHANGE): veth7bea3cb: link becomes ready
[445823.587181] docker0: port 1(veth7bea3cb) entered disabled state
[445823.587335] veth49e9ab9: renamed from eth0
[445823.665299] docker0: port 1(veth7bea3cb) entered disabled state
[445823.670467] device veth7bea3cb left promiscuous mode
[445823.670473] docker0: port 1(veth7bea3cb) entered disabled state
[445824.141726] docker0: port 1(vethf9c8ee7) entered blocking state
[445824.141730] docker0: port 1(vethf9c8ee7) entered disabled state
[445824.142092] device vethf9c8ee7 entered promiscuous mode
[445824.143630] docker0: port 1(vethf9c8ee7) entered blocking state
[445824.143634] docker0: port 1(vethf9c8ee7) entered forwarding state
[445824.406978] eth0: renamed from veth9a8d105
[445824.444401] IPv6: ADDRCONF(NETDEV_CHANGE): vethf9c8ee7: link becomes ready
[445824.589707] docker0: port 1(vethf9c8ee7) entered disabled state
[445824.589911] veth9a8d105: renamed from eth0
[445824.672823] docker0: port 1(vethf9c8ee7) entered disabled state
[445824.677006] device vethf9c8ee7 left promiscuous mode
[445824.677013] docker0: port 1(vethf9c8ee7) entered disabled state
[445824.872205] docker0: port 1(veth5b932c3) entered blocking state
[445824.872210] docker0: port 1(veth5b932c3) entered disabled state
[445824.872507] device veth5b932c3 entered promiscuous mode
[445824.873968] docker0: port 1(veth5b932c3) entered blocking state
[445824.873972] docker0: port 1(veth5b932c3) entered forwarding state
[445825.158730] eth0: renamed from veth0867d24
[445825.182699] IPv6: ADDRCONF(NETDEV_CHANGE): veth5b932c3: link becomes ready
[445825.343046] docker0: port 1(veth5b932c3) entered disabled state
[445825.343259] veth0867d24: renamed from eth0
[445825.410234] docker0: port 1(veth5b932c3) entered disabled state
[445825.414821] device veth5b932c3 left promiscuous mode
[445825.414831] docker0: port 1(veth5b932c3) entered disabled state
[445825.856128] docker0: port 1(vethff473f8) entered blocking state
[445825.856131] docker0: port 1(vethff473f8) entered disabled state
[445825.856350] device vethff473f8 entered promiscuous mode
[445825.856474] docker0: port 1(vethff473f8) entered blocking state
[445825.856476] docker0: port 1(vethff473f8) entered forwarding state
[445826.114645] eth0: renamed from vethb9d482b
[445826.136122] IPv6: ADDRCONF(NETDEV_CHANGE): vethff473f8: link becomes ready
[445826.284932] docker0: port 1(vethff473f8) entered disabled state
[445826.285109] vethb9d482b: renamed from eth0
[445826.352482] docker0: port 1(vethff473f8) entered disabled state
[445826.357780] device vethff473f8 left promiscuous mode
[445826.357802] docker0: port 1(vethff473f8) entered disabled state
[445826.577351] docker0: port 1(vethe26a357) entered blocking state
[445826.577355] docker0: port 1(vethe26a357) entered disabled state
[445826.577665] device vethe26a357 entered promiscuous mode
[445826.577920] docker0: port 1(vethe26a357) entered blocking state
[445826.577923] docker0: port 1(vethe26a357) entered forwarding state
[445826.749937] docker0: port 1(vethe26a357) entered disabled state
[445826.834646] eth0: renamed from veth28a7df8
[445826.867995] IPv6: ADDRCONF(NETDEV_CHANGE): vethe26a357: link becomes ready
[445826.868113] docker0: port 1(vethe26a357) entered blocking state
[445826.868116] docker0: port 1(vethe26a357) entered forwarding state
[445827.034342] docker0: port 1(vethe26a357) entered disabled state
[445827.034452] veth28a7df8: renamed from eth0
[445827.100332] docker0: port 1(vethe26a357) entered disabled state
[445827.107775] device vethe26a357 left promiscuous mode
[445827.107780] docker0: port 1(vethe26a357) entered disabled state
[445827.620245] docker0: port 1(veth079a89a) entered blocking state
[445827.620249] docker0: port 1(veth079a89a) entered disabled state
[445827.620588] device veth079a89a entered promiscuous mode
[445827.620797] docker0: port 1(veth079a89a) entered blocking state
[445827.620800] docker0: port 1(veth079a89a) entered forwarding state
[445827.773894] docker0: port 1(veth079a89a) entered disabled state
[445827.862531] eth0: renamed from veth257f98e
[445827.883824] IPv6: ADDRCONF(NETDEV_CHANGE): veth079a89a: link becomes ready
[445827.883952] docker0: port 1(veth079a89a) entered blocking state
[445827.883956] docker0: port 1(veth079a89a) entered forwarding state
[445884.363765] docker0: port 1(veth079a89a) entered disabled state
[445884.363996] veth257f98e: renamed from eth0
[445884.459146] docker0: port 1(veth079a89a) entered disabled state
[445884.465045] device veth079a89a left promiscuous mode
[445884.465050] docker0: port 1(veth079a89a) entered disabled state
[445887.160859] docker0: port 1(veth787e422) entered blocking state
[445887.160863] docker0: port 1(veth787e422) entered disabled state
[445887.161152] device veth787e422 entered promiscuous mode
[445887.444952] eth0: renamed from vethace2c69
[445887.485732] IPv6: ADDRCONF(NETDEV_CHANGE): veth787e422: link becomes ready
[445887.485822] docker0: port 1(veth787e422) entered blocking state
[445887.485824] docker0: port 1(veth787e422) entered forwarding state
[445887.650551] docker0: port 1(veth787e422) entered disabled state
[445887.650732] vethace2c69: renamed from eth0
[445887.722103] docker0: port 1(veth787e422) entered disabled state
[445887.728094] device veth787e422 left promiscuous mode
[445887.728101] docker0: port 1(veth787e422) entered disabled state
[445888.187296] docker0: port 1(veth02a66d0) entered blocking state
[445888.187300] docker0: port 1(veth02a66d0) entered disabled state
[445888.187581] device veth02a66d0 entered promiscuous mode
[445888.189105] docker0: port 1(veth02a66d0) entered blocking state
[445888.189110] docker0: port 1(veth02a66d0) entered forwarding state
[445888.468910] eth0: renamed from veth7cbeb55
[445888.502100] IPv6: ADDRCONF(NETDEV_CHANGE): veth02a66d0: link becomes ready
[445904.150271] docker0: port 1(veth02a66d0) entered disabled state
[445904.150512] veth7cbeb55: renamed from eth0
[445904.218734] docker0: port 1(veth02a66d0) entered disabled state
[445904.224177] device veth02a66d0 left promiscuous mode
[445904.224184] docker0: port 1(veth02a66d0) entered disabled state
[445906.132394] docker0: port 1(veth1c9efb4) entered blocking state
[445906.132397] docker0: port 1(veth1c9efb4) entered disabled state
[445906.132593] device veth1c9efb4 entered promiscuous mode
[445906.411400] eth0: renamed from vethc8ca158
[445906.452701] IPv6: ADDRCONF(NETDEV_CHANGE): veth1c9efb4: link becomes ready
[445906.452863] docker0: port 1(veth1c9efb4) entered blocking state
[445906.452866] docker0: port 1(veth1c9efb4) entered forwarding state
[447218.910237] vethc8ca158: renamed from eth0
[447218.969103] docker0: port 1(veth1c9efb4) entered disabled state
[447218.971630] docker0: port 1(veth1c9efb4) entered disabled state
[447218.976920] device veth1c9efb4 left promiscuous mode
[447218.976925] docker0: port 1(veth1c9efb4) entered disabled state
[447271.294533] docker0: port 1(vethe07461f) entered blocking state
[447271.294537] docker0: port 1(vethe07461f) entered disabled state
[447271.294929] device vethe07461f entered promiscuous mode
[447271.585015] eth0: renamed from veth6d59b47
[447271.610080] IPv6: ADDRCONF(NETDEV_CHANGE): vethe07461f: link becomes ready
[447271.610208] docker0: port 1(vethe07461f) entered blocking state
[447271.610211] docker0: port 1(vethe07461f) entered forwarding state
[447271.754255] docker0: port 1(vethe07461f) entered disabled state
[447271.754429] veth6d59b47: renamed from eth0
[447271.815156] docker0: port 1(vethe07461f) entered disabled state
[447271.820312] device vethe07461f left promiscuous mode
[447271.820320] docker0: port 1(vethe07461f) entered disabled state
[447273.023921] docker0: port 1(vethbbd1ddb) entered blocking state
[447273.023925] docker0: port 1(vethbbd1ddb) entered disabled state
[447273.024214] device vethbbd1ddb entered promiscuous mode
[447273.024449] docker0: port 1(vethbbd1ddb) entered blocking state
[447273.024452] docker0: port 1(vethbbd1ddb) entered forwarding state
[447273.288548] eth0: renamed from veth254f2fc
[447273.332400] IPv6: ADDRCONF(NETDEV_CHANGE): vethbbd1ddb: link becomes ready
[447292.816983] docker0: port 1(vethbbd1ddb) entered disabled state
[447292.817269] veth254f2fc: renamed from eth0
[447292.872373] docker0: port 1(vethbbd1ddb) entered disabled state
[447292.877868] device vethbbd1ddb left promiscuous mode
[447292.877877] docker0: port 1(vethbbd1ddb) entered disabled state
[447293.701787] docker0: port 1(veth63259b9) entered blocking state
[447293.701791] docker0: port 1(veth63259b9) entered disabled state
[447293.702098] device veth63259b9 entered promiscuous mode
[447293.702324] docker0: port 1(veth63259b9) entered blocking state
[447293.702327] docker0: port 1(veth63259b9) entered forwarding state
[447293.822425] docker0: port 1(veth63259b9) entered disabled state
[447293.950931] eth0: renamed from veth70757f3
[447293.984381] IPv6: ADDRCONF(NETDEV_CHANGE): veth63259b9: link becomes ready
[447293.984549] docker0: port 1(veth63259b9) entered blocking state
[447293.984554] docker0: port 1(veth63259b9) entered forwarding state
[447294.139802] docker0: port 1(veth63259b9) entered disabled state
[447294.139937] veth70757f3: renamed from eth0
[447294.196753] docker0: port 1(veth63259b9) entered disabled state
[447294.203076] device veth63259b9 left promiscuous mode
[447294.203085] docker0: port 1(veth63259b9) entered disabled state
[447294.415038] docker0: port 1(veth9fcccce) entered blocking state
[447294.415042] docker0: port 1(veth9fcccce) entered disabled state
[447294.415371] device veth9fcccce entered promiscuous mode
[447294.415729] docker0: port 1(veth9fcccce) entered blocking state
[447294.415732] docker0: port 1(veth9fcccce) entered forwarding state
[447294.666902] eth0: renamed from veth3b32dae
[447294.690793] IPv6: ADDRCONF(NETDEV_CHANGE): veth9fcccce: link becomes ready
[447294.842500] docker0: port 1(veth9fcccce) entered disabled state
[447294.842668] veth3b32dae: renamed from eth0
[447294.904589] docker0: port 1(veth9fcccce) entered disabled state
[447294.911298] device veth9fcccce left promiscuous mode
[447294.911307] docker0: port 1(veth9fcccce) entered disabled state
[447398.725556] docker0: port 1(vethec7e9f0) entered blocking state
[447398.725560] docker0: port 1(vethec7e9f0) entered disabled state
[447398.725890] device vethec7e9f0 entered promiscuous mode
[447399.057484] eth0: renamed from vethd17c139
[447399.089525] IPv6: ADDRCONF(NETDEV_CHANGE): vethec7e9f0: link becomes ready
[447399.089672] docker0: port 1(vethec7e9f0) entered blocking state
[447399.089675] docker0: port 1(vethec7e9f0) entered forwarding state
[449536.696128] docker0: port 3(veth491a417) entered blocking state
[449536.696131] docker0: port 3(veth491a417) entered disabled state
[449536.696440] device veth491a417 entered promiscuous mode
[449536.989646] eth0: renamed from vetha4181fd
[449537.013525] IPv6: ADDRCONF(NETDEV_CHANGE): veth491a417: link becomes ready
[449537.013675] docker0: port 3(veth491a417) entered blocking state
[449537.013679] docker0: port 3(veth491a417) entered forwarding state
[449703.979378] docker0: port 3(veth491a417) entered disabled state
[449703.979602] vetha4181fd: renamed from eth0
[449704.028286] docker0: port 3(veth491a417) entered disabled state
[449704.034501] device veth491a417 left promiscuous mode
[449704.034507] docker0: port 3(veth491a417) entered disabled state
[450148.733189] docker0: port 1(vethec7e9f0) entered disabled state
[450148.733391] vethd17c139: renamed from eth0
[450148.820417] docker0: port 1(vethec7e9f0) entered disabled state
[450148.825076] device vethec7e9f0 left promiscuous mode
[450148.825081] docker0: port 1(vethec7e9f0) entered disabled state
[450215.686962] docker0: port 1(veth42d6e67) entered blocking state
[450215.686966] docker0: port 1(veth42d6e67) entered disabled state
[450215.687271] device veth42d6e67 entered promiscuous mode
[450215.988911] eth0: renamed from veth4575d4b
[450216.016631] IPv6: ADDRCONF(NETDEV_CHANGE): veth42d6e67: link becomes ready
[450216.016769] docker0: port 1(veth42d6e67) entered blocking state
[450216.016772] docker0: port 1(veth42d6e67) entered forwarding state
[450225.781753] docker0: port 1(veth42d6e67) entered disabled state
[450225.781955] veth4575d4b: renamed from eth0
[450225.853311] docker0: port 1(veth42d6e67) entered disabled state
[450225.859640] device veth42d6e67 left promiscuous mode
[450225.859649] docker0: port 1(veth42d6e67) entered disabled state
[450247.294145] docker0: port 1(vetha96ff0d) entered blocking state
[450247.294150] docker0: port 1(vetha96ff0d) entered disabled state
[450247.294581] device vetha96ff0d entered promiscuous mode
[450247.601972] eth0: renamed from veth46f4d8b
[450247.635218] IPv6: ADDRCONF(NETDEV_CHANGE): vetha96ff0d: link becomes ready
[450247.635363] docker0: port 1(vetha96ff0d) entered blocking state
[450247.635366] docker0: port 1(vetha96ff0d) entered forwarding state
[451668.976127] veth46f4d8b: renamed from eth0
[451669.028557] docker0: port 1(vetha96ff0d) entered disabled state
[451669.032225] docker0: port 1(vetha96ff0d) entered disabled state
[451669.038335] device vetha96ff0d left promiscuous mode
[451669.038338] docker0: port 1(vetha96ff0d) entered disabled state
[451684.345643] docker0: port 1(vethbbc73dc) entered blocking state
[451684.345647] docker0: port 1(vethbbc73dc) entered disabled state
[451684.345921] device vethbbc73dc entered promiscuous mode
[451684.651289] eth0: renamed from vethfc076d1
[451684.675098] IPv6: ADDRCONF(NETDEV_CHANGE): vethbbc73dc: link becomes ready
[451684.675251] docker0: port 1(vethbbc73dc) entered blocking state
[451684.675254] docker0: port 1(vethbbc73dc) entered forwarding state
[463999.878694] vethdc5e3c6: renamed from eth0
[463999.945377] docker0: port 2(vethc410a54) entered disabled state
[463999.946963] docker0: port 2(vethc410a54) entered disabled state
[463999.951396] device vethc410a54 left promiscuous mode
[463999.951400] docker0: port 2(vethc410a54) entered disabled state
[510060.146088] amdgpu: update_invalid_user_pages: Failed to get user pages: -14
[510060.146098] amdgpu: update_invalid_user_pages: Failed to get user pages: -14
[510060.146114] amdgpu: update_invalid_user_pages: Failed to get user pages: -14
[510207.569078] amdgpu: Started evicting pasid 0x8002
[510207.569146] amdgpu: Finished evicting pasid 0x8002
[510208.952127] amdgpu: Started evicting pasid 0x8002
[510208.952211] amdgpu: Finished evicting pasid 0x8002
[510209.930126] amdgpu: Started evicting pasid 0x8002
[510209.930195] amdgpu: Finished evicting pasid 0x8002
[510210.839709] amdgpu: Started evicting pasid 0x8002
[510210.839779] amdgpu: Finished evicting pasid 0x8002
[512673.612722] amdgpu: update_invalid_user_pages: Failed to get user pages: -14
[512673.612737] amdgpu: update_invalid_user_pages: Failed to get user pages: -14
[512673.612751] amdgpu: update_invalid_user_pages: Failed to get user pages: -14
[512757.108405] amdgpu: Started evicting pasid 0x8002
[512757.108478] amdgpu: Finished evicting pasid 0x8002
[512758.542207] amdgpu: Started evicting pasid 0x8002
[512758.542277] amdgpu: Finished evicting pasid 0x8002
[512759.523636] amdgpu: Started evicting pasid 0x8002
[512759.523705] amdgpu: Finished evicting pasid 0x8002
[512761.040997] amdgpu: Started evicting pasid 0x8002
[512761.041063] amdgpu: Finished evicting pasid 0x8002
[527875.516641] amdgpu: Started evicting pasid 0x8002
[527875.516713] amdgpu: Finished evicting pasid 0x8002
[527876.937165] amdgpu: Started evicting pasid 0x8002
[527876.937238] amdgpu: Finished evicting pasid 0x8002
[527877.904923] amdgpu: Started evicting pasid 0x8002
[527877.904993] amdgpu: Finished evicting pasid 0x8002
[527878.831989] amdgpu: Started evicting pasid 0x8002
[527878.832059] amdgpu: Finished evicting pasid 0x8002
[528040.138170] amdgpu: Started evicting pasid 0x8002
[528040.138240] amdgpu: Finished evicting pasid 0x8002
[528041.554280] amdgpu: Started evicting pasid 0x8002
[528041.554350] amdgpu: Finished evicting pasid 0x8002
[528042.529731] amdgpu: Started evicting pasid 0x8002
[528042.529802] amdgpu: Finished evicting pasid 0x8002
[528043.452229] amdgpu: Started evicting pasid 0x8002
[528043.452299] amdgpu: Finished evicting pasid 0x8002

the dmesg log is too long, I separate it into several comments, thanks a lot!

Thanks @dshm
Instead of pasting it here, better to attach as a text file for readability.

Thanks @dshm
Instead of pasting it here, better to attach as a text file for readability.

I upload the log to my github, and you can get the log file in https://github.com/dshm/HIP-Examples-errors/blob/main/dmesgnewlog . Thanks a lot!

@dshm note for the future that you can attach files to GitHub issues. When you are responding to a comment, you should see txt that says "Attach files by dragging & dropping, selecting or pasting them". Or if you prefer, just click on that text and it should open a file browser window for you to select the log.
By the way, thanks for reporting this issue. As a future ROCm user, I appreciate your time in reporting the issue.

Thanks @dshm for the logs.
I tried it on my Vega10 machine and not able to reproduce this issue.
I am not able to reproduce it on Vega20 also.
My card:
43:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] [1002:687f] (rev c1)
root@taccuser-X399-DESIGNARE-EX:/var/lib/jenkins/pytorch/HIP-Examples# ./test_all.sh
==== vectorAdd ====
rm -f ./vectoradd_hip.exe
rm -f vectoradd_hip.o
rm -f /opt/rocm/hip/src/*.o
/opt/rocm/hip/bin/hipcc -g -c -o vectoradd_hip.o vectoradd_hip.cpp
/opt/rocm/hip/bin/hipcc vectoradd_hip.o -o vectoradd_hip.exe
./vectoradd_hip.exe
System minor 0
System major 9
agent prop name Device 687f
hip Device prop succeeded
PASSED!
==== gpu-burn ====
rm -rf build
mkdir -p build
/opt/rocm/hip/bin/hipcc -I/opt/rocm/hip/include -I/opt/rocm/hcc/include -O3 -c -o build/BurnKernel.o BurnKernel.cpp
mkdir -p build
/opt/rocm/hip/bin/hipcc -I/opt/rocm/hip/include -I/opt/rocm/hcc/include -O3 -c -o build/common.o common.cpp
mkdir -p build
/opt/rocm/hip/bin/hipcc -I/opt/rocm/hip/include -I/opt/rocm/hcc/include -O3 -c -o build/AmdGpuMonitor.o AmdGpuMonitor.cpp
mkdir -p build
/opt/rocm/hip/bin/hipcc -I/opt/rocm/hip/include -I/opt/rocm/hcc/include -O3 -c -o build/gpuburn.o gpuburn.cpp
/opt/rocm/hip/bin/hipcc -lm -lpthread -o build/gpuburn-hip build/BurnKernel.o build/common.o build/AmdGpuMonitor.o build/gpuburn.o
Total no. of GPUs found: 1
Init Burn Thread for device (0)
Temps: [GPU0: 34 C] 5s
Burn Thread using device (0)
Temps: [GPU0: 39 C] 4s
Temps: [GPU0: 40 C] 3s
Temps: [GPU0: 40 C] 2s
Temps: [GPU0: 41 C] 1s
Stopping burn thread on device (0)
==== strided-access ====
rm -f strided-access *.o
/opt/rocm/hip/bin/hipcc -std=c++11 -O3 -o strided-access benchmark-hip.cpp
Using device: Device 687f
stride time GB/sec
0 0.000572 419.58
1 0.003649 65.7714
2 0.007097 33.8171
3 0.005024 47.7707
4 0.004909 48.8898
5 0.005881 40.8094
6 0.005121 46.8658
7 0.00603 39.801
8 0.006535 36.7253
9 0.007657 31.3439
10 0.008243 29.1156
11 0.00874 27.46
12 0.008843 27.1401
13 0.009742 24.6356
14 0.010324 23.2468
15 0.011099 21.6236
16 0.011513 20.846
17 0.012132 19.7824
18 0.012364 19.4112
19 0.01255 19.1235
20 0.012629 19.0039
21 0.012954 18.5271
22 0.012902 18.6018
23 0.013123 18.2885
24 0.013135 18.2718
25 0.013172 18.2205
26 0.013002 18.4587
27 0.012911 18.5888
28 0.012796 18.7559
29 0.01265 18.9723
30 0.012496 19.2061
31 0.012511 19.1831
32 0.011337 21.1696
==== rtm8 ====
Using HIP_PATH=/opt/rocm/hip
hipcc -std=c++11 -O3 -o rtm8_hip rtm8.cpp
memory (MB) = 984.096000
pts (billions) = 1.122751
Tflops = 0.075224
dt = 0.680694
pt_rate (millions/sec) = 1649.420371
flop_rate (Gflops) = 110.511165
speedup = 0.404182
==== reduction ====
rm -f reduction _.o /opt/rocm/hip/bin/hipcc -std=c++11 -O3 -o reduction reduction.cpp ./reduction 1024_1024*4
ARRAYSIZE: 1024
Array size: 0.00390625 MB
The average performance of reduction is 0.0293178 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 8388608
ARRAYSIZE: 8388608
Array size: 32 MB
The average performance of reduction is 32.9265 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 16777216
ARRAYSIZE: 16777216
Array size: 64 MB
The average performance of reduction is 52.9247 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 33554432
ARRAYSIZE: 33554432
Array size: 128 MB
The average performance of reduction is 76.0442 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 67108864
ARRAYSIZE: 67108864
Array size: 256 MB
The average performance of reduction is 113.107 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 134217728
ARRAYSIZE: 134217728
Array size: 512 MB
The average performance of reduction is 154.815 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 268435456
ARRAYSIZE: 268435456
Array size: 1024 MB
The average performance of reduction is 224.649 GBytes/sec
VERIFICATION: result is CORRECT
./reduction 536870912
ARRAYSIZE: 536870912
Array size: 2048 MB
The average performance of reduction is 282.746 GBytes/sec
VERIFICATION: result is CORRECT
==== mini-nbody ====
hipcc -I../ -DSHMOO nbody-orig.cpp -o nbody-orig
./nbody-orig 1024
1024, 1.706
./nbody-orig 2048
2048, 3.383
./nbody-orig 4096
4096, 7.786
./nbody-orig 8192
8192, 17.390
./nbody-orig 16384
16384, 39.165
./nbody-orig 32768
32768, 73.177
./nbody-orig 65536
65536, 93.762
./nbody-orig 131072
131072, 97.108
./nbody-orig 262144
262144, 99.304
./nbody-orig 524288
524288, 100.546
hipcc -I../ -DSHMOO nbody-soa.cpp -o nbody-soa
./nbody-soa 1024
1024, 1.740
./nbody-soa 2048
2048, 3.863
./nbody-soa 4096
4096, 8.072
./nbody-soa 8192
8192, 18.658
./nbody-soa 16384
16384, 40.629
./nbody-soa 32768
32768, 73.747
./nbody-soa 65536
65536, 94.576
./nbody-soa 131072
131072, 97.391
hipcc -I../ -DSHMOO nbody-block.cpp -o nbody-block
./nbody-block 1024
1024, 2.025
./nbody-block 2048
2048, 4.665
./nbody-block 4096
4096, 9.586
./nbody-block 8192
8192, 20.975
./nbody-block 16384
16384, 46.853
./nbody-block 32768
32768, 77.429
./nbody-block 65536
65536, 96.900
./nbody-block 131072
131072, 97.142
==== add4 ====
rm -f gpu-stream-hip *.o
/opt/rocm/hip/bin/hipcc -std=c++11 -O3 -c hip-stream.cpp -o hip-stream.o
g++ -std=c++11 -O3 -c -o common.o common.cpp
/opt/rocm/hip/bin/hipcc -std=c++11 -O3 common.o hip-stream.o -lm -o gpu-stream-hip
./gpu-stream-hip
GPU-STREAM
Version: 1.0
Implementation: HIP
GridSize: 26214400 work-items
GroupSize: 1024 work-items
Operations/Work-item: 1
Precision: double
Running kernels 10 times
Array size: 200.0 MB (=0.2 GB) 0 bytes padding
Total size: 1000.0 MB (=1.0 GB)
Using HIP device Device 687f (compute_units=64)
Driver: 321200
d_a=0x7fb944e00000
d_b=0x7fb938400000
d_c=0x7fb92ba00000
d_d=0x7fb91f000000
d_e=0x7fb912600000
Function MBytes/sec Min (sec) Max Average
Copy 384548.399 0.00109 0.00197 0.00135
Mul 377532.588 0.00111 0.00197 0.00133
Add4 341155.315 0.00307 0.00388 0.00334
Triad 349327.187 0.00180 0.00227 0.00202
GEOMEAN 362679.072
./gpu-stream-hip --groups 256 --groupSize 256
GPU-STREAM
Version: 1.0
Implementation: HIP
GridSize: 65536 work-items
GroupSize: 256 work-items
Operations/Work-item: 400
Using looper kernels:
Precision: double
Running kernels 10 times
Array size: 200.0 MB (=0.2 GB) 0 bytes padding
Total size: 1000.0 MB (=1.0 GB)
Using HIP device Device 687f (compute_units=64)
Driver: 321200
d_a=0x7f3b14e00000
d_b=0x7f3b08400000
d_c=0x7f3afba00000
d_d=0x7f3aef000000
d_e=0x7f3ae2600000
Function MBytes/sec Min (sec) Max Average
Copy 363562.481 0.00115 0.00198 0.00135
Mul 365754.150 0.00115 0.00202 0.00134
Add4 336539.076 0.00312 0.00394 0.00341
Triad 340161.077 0.00185 0.00213 0.00200
GEOMEAN 351254.672
./gpu-stream-hip --float
GPU-STREAM
Version: 1.0
Implementation: HIP
Warning: If number of iterations set >= 8, expect rounding errors with single precision
GridSize: 26214400 work-items
GroupSize: 1024 work-items
Operations/Work-item: 1
Precision: float
Running kernels 10 times
Array size: 100.0 MB (=0.1 GB) 0 bytes padding
Total size: 500.0 MB (=0.5 GB)
Using HIP device Device 687f (compute_units=64)
Driver: 321200
d_a=0x7ff416600000
d_b=0x7ff410000000
d_c=0x7ff409a00000
d_d=0x7ff403400000
d_e=0x7ff3fce00000
Function MBytes/sec Min (sec) Max Average
Copy 299079.154 0.00070 0.00112 0.00083
Mul 308430.560 0.00068 0.00116 0.00080
Add4 299994.450 0.00175 0.00261 0.00197
Triad 288726.840 0.00109 0.00165 0.00122
GEOMEAN 298975.761
./gpu-stream-hip --float --groups 256 --groupSize 256
GPU-STREAM
Version: 1.0
Implementation: HIP
Warning: If number of iterations set >= 8, expect rounding errors with single precision
GridSize: 65536 work-items
GroupSize: 256 work-items
Operations/Work-item: 400
Using looper kernels:
Precision: float
Running kernels 10 times
Array size: 100.0 MB (=0.1 GB) 0 bytes padding
Total size: 500.0 MB (=0.5 GB)
Using HIP device Device 687f (compute_units=64)
Driver: 321200
d_a=0x7f889a600000
d_b=0x7f8894000000
d_c=0x7f888da00000
d_d=0x7f8887400000
d_e=0x7f8880e00000
Function MBytes/sec Min (sec) Max Average
Copy 299485.328 0.00070 0.00106 0.00078
Mul 315111.957 0.00067 0.00107 0.00077
Add4 296871.426 0.00177 0.00263 0.00199
Triad 284166.681 0.00111 0.00164 0.00123
GEOMEAN 298707.066
==== cuda-stream ====
rm -f stream *.o
/opt/rocm/hip/bin/hipcc -std=c++11 -O3 -o stream stream.cpp
STREAM Benchmark implementation in HIP
Array size (double precision) = 536.87 MB
using 192 threads per block, 349526 blocks
output in IEC units (KiB = 1024 B)
Function Rate (GiB/s) Avg time(s) Min time(s) Max time(s)
Copy: 354.8481 0.00290536 0.00281811 0.00336909
Scale: 351.3700 0.00292871 0.00284600 0.00332189
Add: 326.6592 0.00468678 0.00459194 0.00524712
Triad: 327.4412 0.00465951 0.00458097 0.00521207

@ROCmSupport Thank you a lot for reply! What are the steps of operation you tried? Could you please give the commands and environment you use in detail? Could it be possible that the problem is graph card related? Though it is vega10, we don’t have Radeon RX Vega 56/64. Did you test the code on Radeon PRO WX 8100?

Hi @dshm
I don't have Radeon Pro WX8100 with us. It is most likely due to problem with the card, i.e, ROCm on specific card(your card).
Recommend you to try with any other ROCm supported card and let me know.

@ROCmSupport

Could you please give the steps of command you use to test in your machine in detail?
And could you please give the test environment in your machine in detail?
I have tried another machine with 6900xt card but fails for other errors. The link to the new issue is https://github.com/RadeonOpenCompute/ROCm/issues/1404
Could you please give me some adivice? Thank you a lot for your time!

Hi @dshm
I don't have Radeon Pro WX8100 with us. It is most likely due to problem with the card, i.e, ROCm on specific card(your card).
Recommend you to try with any other ROCm supported card and let me know.

@ROCmSupport

Could you please give the steps of command you use to test in your machine in detail?
And could you please give the test environment in your machine in detail?
I have tried another machine with 6900xt card but fails for other errors. The link to the new issue is https://github.com/RadeonOpenCompute/ROCm/issues/1404
Could you please give me some adivice? Thank you a lot for your time!

I followed the below steps(given by you) on My Vega10-64 card.
Base OS is Ubuntu 18.04 with 5.4 kernel + ROCm 4.0 installed in it.
Launched docker: rocm/pytorch:rocm4.0_ubuntu18.04_py3.6_pytorch_1.7.0.
I run the test using the following command
git clone https://github.com/ROCm-Developer-Tools/HIP-Examples.git
cd HIP-Examples
git submodule init
git submodule update
./test_all.sh 2>&1 | tee testlog


Fix for double init

Released as https://github.com/bbindreiter/node-red-contrib-alexa-remote2-applestrudel/releases/tag/5.0.43


Menu wordpress target="_blank"

I don't want to debate if it's good or bad to use this attribute :)
I need a target="_blank" to one item of a menu.
I checked the checkbox in the configuration to enable it on the item. But I have the feeling that there is no target in the Timber's context.

Ok I'm sorry I just found it

I'm having the same issue, how did you access the value for the page target?

@DaanRuiter this is something that's re-written for 2.x. In the meantime you can use:
<a href="{{ item.link }}" target="{{ item.meta( '_menu_item_target' ) ? item.meta( '_menu_item_target' ) : '_self' }}">

... which is a bit verbose, but is compatible for both 1.x and 2.x


Stage a new logging library spdlog

Change Description
EPE-2012
Add a new submodule spdlog that is going to replace current fc logging library.
Change Type
Select ONE:

[ ] Documentation

[ ] Stability bug fix

[x] Other

[ ] Other - special case

Testing Changes
Select ANY that apply:

[ ] New Tests

[ ] Existing Tests

[ ] Test Framework

[ ] CI System

[ ] Other

Documentation Additions

[ ] Documentation Additions

Closing the PR, and will use fmt as the feature branch.


Delete certificate rather than just clearing active.

https://github.com/paritytech/second-price-auction/blob/master/src/contracts/MultiCertifier.sol#L60 only clears the active flag but doesn't clear the certifier or the entry.  There does not appear to be any purpose to leaving an inactive certificate as it isn't used anywhere.
Recommend either make use of revoked certificates, add a comment indicating why revoked certificates are useful and why the log isn't enough, or delete certs[_who] .  If you go with the last, consider also removing the .active storage variable and the struct and simplifying to a mapping(address => address) to save on gas.

Leaving it there, in principle, allows one to distinguish between certified-and-then-revoked (or some other attempt at certification that was for some reason unsuccessful) and not certified at all.


Some factory methods for `Domain' don't fully construct valid objects

The Boolean set operation methods that construct instances of Domain don't fill out all the member variables. The missing ones (the mfem_*_ids_) are needed for getting indices into FiniteElementState instances.
This bug is also present in the EntireDomain and EntireBoundary methods, but I'm about to submit a simple fix for those.

I could fix this in its own PR or roll it into the DG one (which is already making some improvements to the Domain class)-- do you have any preference?


Deprecation warning on CommonChunksPlugin. Add SplitChunksPlugin page

Add Tobias as a reviewer since I used his gist as a base for the SplitChunksPlugin page. I've also added a deprecation warning on CommonChunksPlugin one (not deleting it for now since developers and teams who can immediately migrate might need it).

Great initial work!

@skipjack I want to bother you as less as possible, but tagging you here since it's a whole new page that would love to have a look from you.

I notice these docs don't include any information about the enforce cache group setting (undocumented in Sokra's gist). I've been playing around with that option and was hoping to learn more about it from these docs. It seems like it is useful for overriding the base settings for only one cache group. E.g.:
splitChunks: {
	chunks: "async",
	minSize: 30000,
	minChunks: 1,
	maxAsyncRequests: 5,
	maxInitialRequests: 3,
	name: true,
	cacheGroups: {
		default: {
			minChunks: 2,
			priority: -20
			reuseExistingChunk: true,
		},
		vendors: {
			test: /[\\/]node_modules[\\/]/,
			priority: -10
		},
		special: {
			test: myTestFunc,
			enforce: true
		}
	}
}

Please correct me if I am mistaken: The enforce allows the special cache group to ignore the minSize, minChunks, maxAsyncRequests and maxInitialRequests set in the overall cacheGroups config and purely use test to decide what goes into the chunk. What I'm unclear on is how that fits in when used with reuseExistingChunk.

Thanks everyone for all your feedback. Working on updates and getting changes pushed soon.

Thanks everyone for the comments, I'm creating a new pull request since the next branch has been merged and rebase is completely broken from here in files that haven't been touched and I don't want to cause regression on content.
@sokra I will create an issue with some stuff that needs to be revisited or cover in the split chunks article. Thanks for the comments.


fix: add @match for new ChatGPT domain with query parameter

Added @match for https://chatgpt.com/?oai-dm=1 to the Tampermonkey script manifest. This is to handle the new domain for ChatGPT, as the old domain https://chat.openai.com/ now redirects to the new address with the '?oai-dm=1' query parameter. The manifest already includes all variations of the new address except this one.

LGTM. Thank you!


stuffs all offset

the center of the frame is offset USING A CALCULATED CENTER from the size of the frame:

the blue line is supposed to originate from the center

you are stupid, maybe make sure that you return data in a CONSISTENT order


Fix red flash on cancel button when clicking dialogs

Sweetalert is adding a style which activates on click of the button that makes it red.  This is seen for a moment but is annoying.

Need to provide a pretty high level css in main.css to address.  Not ideal as this should be within the component, but attempts to use the variable to style have been unsuccessful


Missing parenthesis in Enum methods throws error in platform but not in compilation time

1. Describe the bug
Missing parenthesis in Enum methods throws error in platform but not in compilation time.
2. To Reproduce
Steps to reproduce the behavior:

Create an Enum

enum 70021 "ABC Sale Type"
{
    value(0; A) {}
    value(1; B) {}
}

Add this code

Txt := Enum::"ABC Sale Type".Names.Get(Enum::"ABC Sale Type".Ordinals.IndexOf(1))

3. Expected behavior
AL compiler should throw a clear error because error is thrown later in platform.
4. Actual behavior
You can compile but an error is thrown when you try to publish: Unexpected value 'NoConversion' of type 'Microsoft.Dynamics.Nav.CodeAnalysis.ConversionKind') Unexpected value 'NoConversion' of type 'Microsoft.Dynamics.Nav.CodeAnalysis.ConversionKind'
5. Solution:
Add parenthesis to Names() method and Ordinals() methods
Txt := Enum::"ABC Sale Type".Names().Get(Enum::"ABC Sale Type".Ordinals().IndexOf(1))

6. Versions:

AL Language: I guess 12.1
Visual Studio Code: 1.85.1
Business Central: 23.1

Final Checklist
Please remember to do the following:

[X] Search the issue repository to ensure you are reporting a new issue
[X] Reproduce the issue after disabling all extensions except the AL Language extension
[X] Simplify your code around the issue to better isolate the problem

Thank you for the repro, it's super useful. Happy new year!

Duplicate/related to #7477 ?

This specific bug should be fixed (#7477 is still open though)


Renaming Action Parameter causes Binding to Fail

I have an action on a controller that fails without the [Bind(Prefix="")].  Without it, the keys in the ModelState are description.Name, description.Abstract, and description.Description, not Name, Abstract, and Description.  This was working until I change the parameter name and type during some refactoring.  Not sure exactly what change cause the issue.
        // POST: ApiDoc/Edit/
        [HttpPost]
        [ValidateAntiForgeryToken]
        public async Task<IActionResult> Edit([Bind(Prefix ="")]ApiGroupDescription description)
        {
            if (ModelState.IsValid)
            {
                var obj = await _service.GetBaseAsync(description.Id);
                if (obj == null)
                    return HttpNotFound();

                if (await TryUpdateModelAsync(obj))
                {
                    await _service.UpdateAsync(obj);
                    return RedirectToAction("Details", new { id = obj.Id });
                }
            }
            return View(description);
        }

The cause of this is that the bind is ambiguous because you have a parameter named description with a Description property.
Model binding first looks at the request to see if any data matches the parameter name. In this case you have an entry for Description (which you intended to match the property name), so the system assumes all of the inputs are supposed to look like description.Description, description.Name, etc...
A few things you might want to consider:

Using [Bind(...)] in this way is totally fine, it's there so you can configure what model binding does.
You could also rename the parameter or property
You could also pass a field prefix when generating the form so that the form fields are like description.Name

If you don't like this behavior, you could also write a convention to apply an implicit [Bind(Prefix ="")] to everything in your app. If you need a sample let me know.

I fail to see how this is ambiguous.  The parameter is a complex type, so can't be bound to a single parameter.  This would only get ambiguous if there were multiple parameters with common property names.
I think the case where there is only one parameter is the typical use case, and it should be as robust a possible.  In this case, there was not error or warning logged, it just failed to bind, resulting in several wasted hours.

The debug log actually does a fairly reasonable job logging what it looked for:
> dbug: Microsoft.AspNetCore.Mvc.ModelBinding.ParameterBinder[22]
>       Attempting to bind parameter 'description' of type 'MvcSandbox.Controllers.DescriptionModel' ...
> dbug: Microsoft.AspNetCore.Mvc.ModelBinding.Binders.ComplexTypeModelBinder[44]
>       Attempting to bind parameter 'description' of type 'MvcSandbox.Controllers.DescriptionModel' using the name 'description' in request data ...
> dbug: Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder[15]
>       Could not find a value in the request with name 'description.Description' for binding property 'MvcSandbox.Controllers.DescriptionModel.Description' of type 'System.String'.
> dbug: Microsoft.AspNetCore.Mvc.ModelBinding.Binders.SimpleTypeModelBinder[14]

Perhaps an analyzer (https://github.com/aspnet/Mvc/issues/7753) would better improve the experience, while not changing the behavior?

This would be a great case for an analyzer. We know this is confusing and users perceive it as buggy even though it's unfortunately intended to work the way it does.

Will the analyzer then only give me a barely visible grey underlining when I happen to have the controller file open? Or will it also make sure I notice the issue when I add a member with a conflicting name to a model class?


fix: include correct username for deploy:report in async deploy

What does this PR do?
organizes formatters specific to mdapi under formatters/mdapi and source under formatters/source
adds -u <username> output to async deploys
 ➜  sfdx force:source:deploy -p force-app/main/default/classes -w 0
*** Deploying v52.0 metadata with SOAP API v53.0 connection ***
Deploy ID: 0Af1F00002BjnhfSAB
Deploy has been queued.

Run sfdx force:source:deploy:cancel -i 0Af1F00002BjnhfSAB -u<EMAIL_ADDRESS>to cancel the deploy.
Run sfdx force:source:deploy:report -i 0Af1F00002BjnhfSAB -u<EMAIL_ADDRESS>to get the latest status.

 ➜  sfdx force:mdapi:beta:deploy -d object -w 0
Deploy ID: 0Af1F00002BkUN8SAN
*** Deploying with SOAP ***
Deploy has been queued.

Run sfdx force:mdapi:deploy:cancel -i 0Af1F00002BkUN8SAN -u<EMAIL_ADDRESS>to cancel the deploy.
Run sfdx force:mdapi:beta:deploy:report -i 0Af1F00002BkUN8SAN -u<EMAIL_ADDRESS>to get the latest status.

What issues does this PR fix or reference?
@W-5556853@

QA notes:
Using dreamhouse-lwc
✅ source deploy shows default username in the project
sfdx force:source:deploy --sourcepath force-app -w 0
...
Run sfdx force:source:deploy:cancel -i 0AfP000001LPu3DKAT -u<EMAIL_ADDRESS>to cancel the deploy.
Run sfdx force:source:deploy:report -i 0AfP000001LPu3DKAT -u<EMAIL_ADDRESS>to get the latest status.

✅ metadata deploy shows default username in the project
sfdx force:mdapi:beta:deploy -d mdapi -w 0
...
Run sfdx force:mdapi:deploy:cancel -i 0AfP000001LPuIjKAL -u<EMAIL_ADDRESS>to cancel the deploy.
Run sfdx force:mdapi:beta:deploy:report -i 0AfP000001LPuIjKAL -u<EMAIL_ADDRESS>to get the latest status.


IsUp now requires https

This repository has been deprecated for awhile in favor of npm packages, and it looks like this one was extracted to https://github.com/pric/hubot-isup. We are in the process of finding scripts that have been extracted, and deprecating them over in https://github.com/github/hubot-scripts/issues/1641, so I'd give that a try to see if it works any better.


When I run the train_ppo_llama_ray.sh script, the async_fit_actor_model gets stuck

When train_ppo_ray.py reaches the line refs = actor_model.async_fit_actor_model(critic_model, ref_model, reward_models, reward_fn=reward_fn, vllm_engines=vllm_engines), it gets stuck. I suspect that the issue might be caused by torch.distributed.barrier() getting stuck during the initialization of ActorPPOTrainer.

what is your vllm version

vllm 0.4.0

please use vllm 0.4.2


kubernetes on arm64 platform support

i want to setup kubernetes and minkube   in my arm64 debian qemu vm  but  i'm unable to do this
because in the official site there is no any link is given to arm64 platform kubernetes and minikube setup ,
can you plz provide any blog or resource by which i can setup kubernetes and minikube on arm64 debian platform

Documenting Kubernetes specifically for the ARM64 /AArch64 platform would be a bit of a stretch. You're very welcome to contribute documentation @harsh151028. Also, I have a PR about using kubeadm that should be a bit clearer once I tidy it up.
/kind feature
/priority awaiting-more-evidence


add changed notification listener error

if I do
listener = UserNotificationListener.get_current()
listener.add_notification_changed(handler)

where handler is another defined function
I get
OSError: [WinError -2147023728] Element not found

I know I have access to notifications because
notifs=await listener.get_notifications_async(1)

works
any fix?
thanks

Which line triggers the error?

UserNotificationListener.get_current()

This should be UserNotificationListener.current. It is a property.

ah, sorry. the next line:
listener.add_notification_changed(handler)
triggers the erorr

does the error still happen if you fix the current property?

This should be UserNotificationListener.current. It is a property.

Actually, I guess this is wrong because of pywinrt/pywinrt#13. Static properties currently are not implemented like instance properties.

well, yes.
AttributeError: type object '_winsdk_Windows_UI_Notifications_Management.UserNo' has no attribute 'current'
still, I guess all that would do is call get_current under the hood, right?
would it help if I gave you the whole code to test? although it is not much, just imports.

I'm not sure that anything in the Windows.UI namespace is really usable outside of a Windows Store app at this point.

ok. it seems partially usable, at least, since I can get the notification list and get_access_request_async returns allowed, only the event doesn't work. That's why I thought it should be functional.

The issue is resolved when installing Python from the Windows store rather than python.org.
I was using Python 3.10.9, installed with the official 64-bit installer, and the program operated as expected because I was using the python3 command, which was pointing to the Windows Store Python3 installation.
I sent the script to a coworker who installed 3.11.1, and he received the error. I installed 3.11.1 and replicated the same error as the OP.
Steps to resolve the bug:

Uninstall all Python-related apps and programs from  Apps  & Features   ( this isn't entirely necessary, but a good sanity check)
Open a new PowerShell and type python3. This should launch the Windows Store Python 3.10 page.
Click the Get button to install Python 3.10.
After the installation, restart your PowerShell and verify the installation with python3 --version. You should see Python 3.10.9 as the output.
Install pywinsdk with python3 -m pip install winsdk.

These steps resolved the error on two separate machines, and the program successfully listened for new notifications.

The issue is resolved when installing Python from the Windows store rather than python.org.
I was using Python 3.10.9, installed with the official 64-bit installer, and the program operated as expected because I was using the python3 command, which was pointing to the Windows Store Python3 installation.
I sent the script to a coworker who installed 3.11.1, and he received the error. I installed 3.11.1 and replicated the same error as the OP.
Steps to resolve the bug:

Uninstall all Python-related apps and programs from  Apps  & Features   ( this isn't entirely necessary, but a good sanity check)
Open a new PowerShell and type python3. This should launch the Windows Store Python 3.10 page.
Click the Get button to install Python 3.10.
After the installation, restart your PowerShell and verify the installation with python3 --version. You should see Python 3.10.9 as the output.
Install pywinsdk with python3 -m pip install winsdk.

These steps resolved the error on two separate machines, and the program successfully listened for new notifications.

I can confirm that the error isn't present on the Microsoft Store edition of Python.
I've looked EVERYWHERE for a solution, thank you @gradnerj


Add more ignorable errors for reconcilation runner

consider x509: certificate is valid... as ignroable error, stop reconcilation to let reonciler fail-fast.
Related issue: https://github.tools.sap/kyma/backlog/issues/3472

/test pre-main-kyma-incubator-reconciler

@ruanxin : I fear we have to update the code-owners file.. I'm no longer able to approve PRs


Sl/sbx error

What does this PR do?
fix results in INSUFFICIENT_ACCESS error with org refresh/resume sandbox
What issues does this PR fix or reference?
@W-16961973@
Github issue link: https://github.com/forcedotcom/cli/issues/3048

QA notes

after running the refresh command and waiting >3 hours, I saw the error
✅ : after linking this, no error


[install scripts] Add support of DD_SITE

What does this PR do?
Adds support of DD_SITE env var in install scripts. Follow-up to https://github.com/DataDog/datadog-agent/pull/2412, see details there
Additional Notes
Should be merged once 6.6.0 is out

Codecov Report

Merging #2414 into master will increase coverage by 4.52%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2414      +/-   ##
==========================================
+ Coverage   56.69%   61.21%   +4.52%
==========================================
  Files         378      259     -119
  Lines       23847    16685    -7162
==========================================
- Hits        13519    10213    -3306
+ Misses       9414     5913    -3501
+ Partials      914      559     -355

Impacted Files
Coverage Δ

pkg/util/docker/util_common.go
0% <0%> (-100%)
:arrow_down:

pkg/tagger/collectors/catalog.go
0% <0%> (-100%)
:arrow_down:

pkg/util/docker/event_types.go
0% <0%> (-85.72%)
:arrow_down:

pkg/util/containers/metrics/common.go
0% <0%> (-80.96%)
:arrow_down:

pkg/logs/input/file/file_provider.go
0% <0%> (-79.07%)
:arrow_down:

pkg/logs/input/file/tailer.go
0% <0%> (-70.64%)
:arrow_down:

pkg/metadata/host/host.go
1.55% <0%> (-61.25%)
:arrow_down:

pkg/logs/config/integration_config.go
18.86% <0%> (-54.72%)
:arrow_down:

pkg/logs/input/file/scanner.go
0% <0%> (-49.28%)
:arrow_down:

pkg/logs/input/file/rotate.go
0% <0%> (-41.18%)
:arrow_down:

... and 127 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 102f21c...aeaab3e. Read the comment docs.