chore!: remove legacy patch pods fallback

PR Takeover https://github.com/argoproj/argo-workflows/pull/12976. Description is mostly verbatim
Motivation

the fallback is old and insecure, and the error confuses users as it's not mentioned in the docs (as it's legacy and a fallback)

e.g. https://github.com/argoproj/argo-workflows/issues/12783 and also frequently on Slack. See #13041 for more such examples of confusion

it's also tech debt that we have to write code around specifically right now
it's no longer needed and hasn't been the main RBAC in a few versions, so remove it in the next breaking minor release

Modifications

remove the Executor code that patches pods
remove the operator code that reads the patched annotations

Verification
Tests pass

@agilgur5 my WIP takeover. I'll finish this at some point this week.

@agilgur5 Some of these tests are failing because some of the test workflows use the argo service account and the argo service account doesn't have create and patch permissions for workflowtaskresults. Would there be an issue with adding those permissions to the argo-role?

some of the test workflows use the argo service account and the argo service account doesn't have create and patch permissions for workflowtaskresults.

Oh. That's surprising, that means these tests have been using the wrong RBAC for some time and relying on the fallback 😬

Would there be an issue with adding those permissions to the argo-role?

Yes, especially in the official install manifests as you have them now. The Controller does not need those privileges and so shouldn't have them.
The Executor should really have it's own SA & Role. We can add those to the test overlays. I don't remember which install the tests use, but if they already use the quick start, I believe there is an Executor Role in those manifests already (although I might be mistaken, it may just have excess privileges in general since it's a non-prod quick start).

Yes, the tests use the various quick start manifests depending on the profile you choose. There is an executor role (same as in the docs) that is bound to the default service account. Are you suggesting that I bind the executor role to the argo service account in the e2e manifest mixins?
Below is one of the test cases where the argo service account needs the executor permissions. If i'm not mistaken the template service account (not just the pod service account) needs the executor permissions. Since it is creating a resource, it also needs the argo permissions.
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: k8s-resource-tmpl-with-pod-
spec:
  serviceAccount: argo
  entrypoint: main
  templates:
    - name: main
      serviceAccountName: argo
      resource:
        action: create
        setOwnerReference: true
        successCondition: status.phase == Succeeded
        failureCondition: status.phase == Failed
        manifest: |
          apiVersion: v1
          kind: Pod
          metadata:
            generateName: k8s-pod-resource-
          spec:
            serviceAccountName: argo
            containers:
            - name: argosay-container
              image: argoproj/argosay:v2
              command: ["/argosay"]
            restartPolicy: Never

that is bound to the default service account.

Ah right of course since quick start.

Are you suggesting that I bind the executor role to the argo service account in the e2e manifest mixins?

I could also create a dedicated service account for these tests with the required permissions, I suppose.

The latter would be more correct and least privilege (i.e. less possible future bugs with regard to the tests)

If I'm not mistaken, the template service account (not just the pod service account) needs the executor permissions

The Pod within the resource doesn't need an SA at all since it just runs argosay. Only the template needs the SA, which runs the create action and ofc needs Executor permissions.

that is bound to the default service account.

Ah right of course since quick start.

Are you suggesting that I bind the executor role to the argo service account in the e2e manifest mixins?

I could also create a dedicated service account for these tests with the required permissions, I suppose.

The latter would be more correct and least privilege (i.e. less possible future bugs with regard to the tests)

If I'm not mistaken, the template service account (not just the pod service account) needs the executor permissions

The Pod within the resource doesn't need an SA at all since it just runs argosay. Only the template needs the SA, which runs the create action and ofc needs Executor permissions.

I just realized the pod create permissions are bound to the default service account with the pod-manager role. Switching the tests that used the argo service account to use the default service account instead.

@agilgur5 I think this test is/was wrong? The container doesn't inherit permissions from the executor, right?
I changed
  executor:
    serviceAccountName: argo

to
  executor:
    serviceAccountName: default

The full test
func (s *WorkflowSuite) TestContainerTemplateAutomountServiceAccountTokenDisabled() {
	s.Given().Workflow(`
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: get-resources-via-container-template-
  namespace: argo
spec:
  serviceAccountName: argo
  automountServiceAccountToken: false
  executor:
    serviceAccountName: default
  entrypoint: main
  templates:
    - name: main
      container:
        name: main
        image: bitnami/kubectl
        command:
          - sh
        args:
          - -c
          - |
           kubectl get cm
`).
		When().
		SubmitWorkflow().
		WaitForWorkflow(fixtures.ToBeSucceeded, time.Minute*11).
		Then().
		ExpectWorkflow(func(t *testing.T, metadata *metav1.ObjectMeta, status *wfv1.WorkflowStatus) {
			assert.Equal(t, wfv1.WorkflowSucceeded, status.Phase)
		})
}

The failure
    workflow_test.go:53: condition never and cannot be met because the workflow is done
Checking expectation get-resources-via-container-template-slp6q
get-resources-via-container-template-slp6q : Failed Error (exit code 1)
    workflow_test.go:56:
        	Error Trace:	/home/runner/work/argo-workflows/argo-workflows/test/e2e/workflow_test.go:56
        	            				/home/runner/work/argo-workflows/argo-workflows/test/e2e/fixtures/then.go:69
        	            				/home/runner/work/argo-workflows/argo-workflows/test/e2e/fixtures/then.go:44
        	            				/home/runner/work/argo-workflows/argo-workflows/test/e2e/workflow_test.go:55
        	Error:      	Not equal:
        	            	expected: "Succeeded"
        	            	actual  : "Failed"

        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1,2 +1,2 @@
        	            	-(v1alpha1.WorkflowPhase) (len=9) "Succeeded"
        	            	+(v1alpha1.WorkflowPhase) (len=6) "Failed"

        	Test:       	TestWorkflowSuite/TestContainerTemplateAutomountServiceAccountTokenDisabled

Shouldn't we be expecting the failure?

@agilgur5 Ready for review

Oh I totally forgot to add a release note in my initial variant of the PR -- we should add a small one to the 3.6 upgrading.md and just link to the Workflow RBAC page (where I removed the old RBAC in #12975)

Added.

This looks good to me, thanks for the work on it @Garett-MacGowan.
I was wondering if we could modify the error message you see in the GUI to include a link to the documentation for fixing it as it's really common to see people with incorrect RBAC still. Currently you see
Error (exit code 1): workflowtaskresults.argoproj.io is forbidden: User "system:serviceaccount:argo:default" cannot create resource "workflowtaskresults" in API group "argoproj.io" in the namespace "argo"

which is probably obvious to you and I, but for most people who hope it'd just work, they'll be confused.
It doesn't have to be a part of this PR though.
I'll leave it to @agilgur5 to have a look over it.

This looks good to me, thanks for the work on it @Garett-MacGowan.
I was wondering if we could modify the error message you see in the GUI to include a link to the documentation for fixing it as it's really common to see people with incorrect RBAC still. Currently you see
Error (exit code 1): workflowtaskresults.argoproj.io is forbidden: User "system:serviceaccount:argo:default" cannot create resource "workflowtaskresults" in API group "argoproj.io" in the namespace "argo"

which is probably obvious to you and I, but for most people who hope it'd just work, they'll be confused.
It doesn't have to be a part of this PR though.
I'll leave it to @agilgur5 to have a look over it.

@Joibel Thanks. I could add a link to the GUI. Will put it in another PR.

@Garett-MacGowan, any chance you could bring this up to date so it can be merged?

@Garett-MacGowan, any chance you could bring this up to date so it can be merged?

Sure, I'll work on it today

AnnotationKeyProgress

Thanks @jswxstw.
@Joibel sorry, life stuff happened. I'll get to this today, hopefully.

This looks good to me, thanks for the work on it @Garett-MacGowan.
I was wondering if we could modify the error message you see in the GUI to include a link to the documentation for fixing it as it's really common to see people with incorrect RBAC still. Currently you see
Error (exit code 1): workflowtaskresults.argoproj.io is forbidden: User "system:serviceaccount:argo:default" cannot create resource "workflowtaskresults" in API group "argoproj.io" in the namespace "argo"

which is probably obvious to you and I, but for most people who hope it'd just work, they'll be confused.
It doesn't have to be a part of this PR though.
I'll leave it to @agilgur5 to have a look over it.

Could you point me to where this is displayed in the UI? It has been a while. Thanks.

@Joibel @agilgur5 Ready for review.
@jswxstw Do you mind taking a look to verify that what I've done is what you had in mind?
Thanks.

@jswxstw Do you mind taking a look to verify that what I've done is what you had in mind?

It looks good to me now.
By the way, does this document need to be updated since its content is outdated?

The executor will read this file every 3s and if there was an update, patch the pod annotations with workflows.argoproj.io/progress: N/M.

@jswxstw Do you mind taking a look to verify that what I've done is what you had in mind?

It looks good to me now.
By the way, does this document need to be updated since its content is outdated?

The executor will read this file every 3s and if there was an update, patch the pod annotations with workflows.argoproj.io/progress: N/M.

What in particular is out of date? The pod patches still happen, they just need the RBAC now. See monitorProgress of executor.go

What in particular is out of date? The pod patches still happen, they just need the RBAC now. See monitorProgress of executor.go

Aren’t pod patches removed by the current PR and progress can only be reported to WorkflowTaskResult now?

Aren’t pod patches removed by the current PR and progress can only be reported to WorkflowTaskResult now?

Right, sorry. The updates to progress are done via WorkflowTaskResult and are reflected by
newNode.Progress = result.Progress
...
woc.wf.Status.Nodes.Set(nodeID, *newNode)

in taskResultReconciliation. The pod annotations are not updated anymore.
How about the following change?
Instead of:

The executor will read this file every 3s and if there was an update, patch the pod annotations with workflows.argoproj.io/progress: N/M. The controller picks this up and writes the progress to the appropriate Status properties.

We can say:

The executor will read this file every 3s, and if there was an update, create a WorkflowTaskResult containing the progress update. The controller picks this up and writes the progress to the appropriate Status properties.

Wait... I just checked the file on my branch. It has already been updated...
The executor will read this file every 3s and if there was an update,
patch the matching `WorkflowTaskResults` resource with the value `N/M`.
The controller picks this up and writes the progress to the appropriate Status properties
every 1m.

@agilgur5 I think this is ready for review.

One suggestion, but LGTM

Thanks @Joibel

I was wondering if we could modify the error message you see in the GUI to include a link to the documentation for fixing it as it's really common to see people with incorrect RBAC still. Currently you see
Error (exit code 1): workflowtaskresults.argoproj.io is forbidden: User "system:serviceaccount:argo:default" cannot create resource "workflowtaskresults" in API group "argoproj.io" in the namespace "argo"

Could you point me to where this is displayed in the UI? It has been a while. Thanks.

Sorry I forgot to respond to this at the time Alan wrote it and then had not been feeling well for much of the past week.
This does not appear in the UI per se, it appears in logs, which can appear in the UI. I did specifically address this with an FAQ entry in https://github.com/argoproj/argo-workflows/pull/13041 (as listed in the PR description).
That should be changed for 3.6 then.
Alan specifically meant to catch that error and instead return a link to the docs. This line logs a link to the docs, but does not change the end error


Fix broken link of content/ja/docs/contribute/_index.md

tag: release-1.26 has content/ja/docs/contribute/new-content/overview.md,
But tag: main has no content/ja/docs/contribute/new-content/overview.md
Close:https://github.com/kubernetes/website/issues/44645

The target page on deploy preveiw site:

https://deploy-preview-44652--kubernetes-io-main-staging.netlify.app/ja/docs/contribute/

/lgtm
Thank you for creating this PR.
Nice catch!

@atoato88
I resolved the conflict, so can you review again, please?

/assign @nasa9084

/lgtm
Sorry for the late review.

/approve


Require JSON files from same environment as modules

Fixes #228.
Advice for how to unit test this welcome. I added JSON to the environment mock to make sure existing tests pass, but couldn't figure out how to create a new mocked environment that will let me assert that the issue described in #228 is fixed.

Can this just get merged without new tests? It's taken me a frustrating amount of time to track this down only to find that it's been fixed but not merged for 4 months!
For whatever reason .json files don't pass through the preprocessor, so I can't even try to form a global workaround there.

@dmnd, @spicyj, this looks reasonable. Do we have an existing JSON test to confirm the change is OK?

Yes: https://github.com/facebook/jest/blob/v0.4.1/src/HasteModuleLoader/tests/HasteModuleLoader-requireModule-test.js#L106-L137

OK, sounds good, thanks!


executor: scancode: Use pip package

Scancode now has a working pip package. Update the executor to
use it instead of running it from the cloned git repository.

Updated the executor's documentation.
Called the general scancode package which should be installed
either on the system or in a virtual environment.
Updated the README with instructions on how to run tern with
scancode

Signed-off-by: Nisha K<EMAIL_ADDRESS>

@rnjudge we'll have to cut another release for the documentation to be valid.

@rnjudge we'll have to cut another release for the documentation to be valid.

@nishakm should we wait for the other scancode fix that's coming?

@rnjudge we'll have to cut another release for the documentation to be valid.

@nishakm should we wait for the other scancode fix that's coming?

We don't have to. But the script will fail if we merge this in and don't release an equivalent PyPI package. I say we wait till after the holidays to merge this change in.


Reading vector3 position of each marker in Unity

Hello, i would like to know how i can implement a function in cpp that return the position of all detected spheres in Unity ! Thank you

Hey, for this you need to grab the irToolCenters in processframe, then transform their position into world space and subsequently into unity coordinates. Then make these positions available in unity by creating a new C# binding function that returns an array of vector3

Thank you for you answer ! i am currently facing an issue with the position and orientation of the model all the parameters seems correct but the data is noisy and the orientation and position are sometimes inaccurate depending on the  point of view or the distance from camera ? what do you suggest doing in that case since you already implemented Kalman filter and low pass filter to filter noises ?

Are you using flat markers or reflective spheres?
The best results will be with bigger markers (spheres are also more reliable than flat), as well as bigger distances between each individual marker. This all needs to be within 1m distance to the headset.


Add ability to fully parse browsers/os that contain spaces within token

Currently it will report only 'Xbox' given the following user agent.
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Xbox; Xbox One)

This has been added.


[WARNING]: Failure when attempting to use callback plugin: 'module_name'

I'm getting the following error when trying to use the plugin:
 [WARNING]: Failure when attempting to use callback plugin (</opt/ubik/playbooks/callback_plugins/datadog_callback.CallbackModule object at 0x7efd6cc80c90>):
'module_name'

Searching the issues, I've someone with a similar case: https://github.com/DataDog/ansible-datadog-callback/pull/13#issuecomment-217079134
Using Ansible v2.0
Any idea?

@olivielpeau this looks like it did the trick, the error is gone.

Fixed by #19


Update dependencies

A lot of dependencies are out of date.
especially react and react-dom which are on 15.x
We should be at least on 16.x
And prop-types are its own package now.

what about this PR? You gonna merge it in few days?

@wuweiweiwu @szaudowsky I will upgrade dependencies

done https://github.com/storybooks/react-treebeard/pull/168


Small fixes needed to run HARMONI without Docker.

Most of these changes are relevant to absolute path avoidance (relative paths and $(find ...) are much better usually) and dependency issues. There may be more, this is just what I encountered when getting it all running myself.

Had to replace commits (force push) with identical content due to invalid history on develop. Content still exactly the same.


fix: 5634 - refresh of price lazy counters when accessing lists

What

About a month ago, we switched to "lazy" counts (e.g. my prices) for the user page: we count only the very first time, or on demand (refresh button).
That brings incoherence when we go to the list page and then back to the "counts" page: the lazy count was not explicitly refreshed and kept its old value.
The purpose of this PR is to refresh the price lazy counts each time we go to the corresponding list page (that of course computes the latest counts).

Screenshots
For "Derniers prix ajoutés" = latest added prices

lazy 34441
displayed list
refreshed lazy 37199

Fixes bug(s)

Fixes: #5634

Impacted files

get_prices_model.dart: added a LazyCounterPrices? parameter
lazy_counter.dart: added a bool notify parameter
lazy_counter_widget.dart: now refreshed by "external" new count
price_user_button.dart: added a LazyCounterPrices parameter to have the counter refreshed
product_prices_list.dart: now setting the lazy counter when displaying the list
user_preferences.dart: added a bool notify parameter for the lazy counter setter
user_preferences_account.dart: added a LazyCounterPrices parameter to have the counter refreshed

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

Project coverage is 6.81%. Comparing base (4d9c7fc) to head (a121e3d).
Report is 351 commits behind head on develop.

Files with missing lines
Patch %
Lines

...app/lib/pages/preferences/lazy_counter_widget.dart
0.00%
12 Missing :warning:

.../lib/data_models/preferences/user_preferences.dart
0.00%
5 Missing :warning:

...ooth_app/lib/pages/prices/product_prices_list.dart
0.00%
5 Missing :warning:

...smooth_app/lib/pages/preferences/lazy_counter.dart
0.00%
2 Missing :warning:

...smooth_app/lib/pages/prices/price_user_button.dart
0.00%
1 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##           develop   #5678      +/-   ##
==========================================
- Coverage     9.54%   6.81%   -2.74%
==========================================
  Files          325     404      +79
  Lines        16411   21516    +5105
==========================================
- Hits          1567    1466     -101
- Misses       14844   20050    +5206

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

Thank you @teolemon for your reviews!


Upgrade Zookeeper Operator dependency

The Zookeeper Operator v0.2.10 has been released: https://github.com/pravega/zookeeper-operator/releases/tag/v0.2.10
We should upgrade our dependency, and add support for new options.

v0.2.11 is now available.

v0.2.12 is now out and very recent, so we should target that. Looks like mostly bug fixes and a few additional config options.

Opened a ticket related to the upgrade, https://github.com/pravega/zookeeper-operator/issues/378.
Because we can use an empty value for the new spec.Probes ZK field, we will have to do zkCluster.WithDefaults() before submitting creating/updating/etc the object. This very much ties the Solr Operator down, making it essential that the version of the Zookeeper Operator that users are running is the same as the version the Solr Operator has as a dependency.


Improve 7zip-15-05.vm

At the moment 7zip is on path, change it by 7z.
@vm-packages do we agree on removing 7zip from the Utilities folder? I tend to think we don't need a shortcut for this tool as it is not really an analysis tool and it is already added to the right menu. But it can be used for things like extracting NSIS scripts. So it can be considered an analysis tool as well.
Closes https://github.com/mandiant/VM-Packages/issues/756

@emtuls

As an alternative, we could possibly put them inside of the Raw Tools Dir if we think there's a potential that having access to the binary shortcuts might be useful?

How do you purpose this shortcut to be used? I can't think of a reason to want to keep the shortcut in any location apart from finding it in the Tools directory (if we consider it to be an analysis tool, what I argue is not), but maybe I am missing something. 🤔

@emtuls

As an alternative, we could possibly put them inside of the Raw Tools Dir if we think there's a potential that having access to the binary shortcuts might be useful?

How do you purpose this shortcut to be used? I can't think of a reason to want to keep the shortcut in any location apart from finding it in the Tools directory (if we consider it to be an analysis tool, what I argue is not), but maybe I am missing something. 🤔

I don't think I can think of any reason I would, as I prefer the right click option, but I was airing on the side of caution that there may be users that prefer the method of dragging a file onto the shortcut to open it in 7z, or they might not have a right click (a bit rare though, especially with modern hot keys built into Windows).
Outside of that. I'm all for making the change to remove it if those use cases aren't ones we should consider. :)

Agreed we dont need a shortcut for it


Display tokenscript on spawnable contract magic links (DMZ)

https://github.com/AlphaWallet/alpha-wallet-android/pull/1014


Node.instance() not found

Godot version: 3.2.stable.version
OS/device including version: Windows 10
Issue description: Hi all! I'm new using the Godot, and I'm loving eery moment of it. But I've stumbled into a small problem. It all started with the game I was working on crashing while the remote inspector where selected. It was giving a windows error: access violation. I've eventually figured it out that the problem lied on my ChangeScene.gd code. So to test it, I've created a simple project that switches between 2 scenes using the brackground loading script that I've used (it is the same that is at https://docs.godotengine.org/en/3.2/tutorials/io/background_loading.html). But now, in this new project, the Debugger displays the error: Invalid Call. Nonexistent function 'instance' in base GDScript.
The thing is that it works (almost) normally on my other project.
Steps to reproduce: Just try to run the project.
Minimal reproduction project: https://github.com/teko1987/InstanceError

Sorru, the steps to reproduce is to run the scene and click the button!

The error is correct. instance() is a method of PackedScene, not of GDScript.
Note that in the project you uploaded, you are doing ChangeScene.load_scene("res://Scene2.gd"), when it should be ChangeScene.load_scene("res://Scene2.tres").

Thank you! I feel bad for not seeing that mistake... ^^'


Hello, I want to adjust the distance of the recognition gesture. When I stand at 1.5m, the camera can't recognize my hand. Is there any way to solve this problem

@mgyong I hope to get your help. Thank you

@Sanerly Can you provide images or video examples of how the hand model fails to recognize the hand?

Screenrecorder-2020-01-07-18-19-51-343.zip
Hello, this is the video I recorded. When my hand was far away, the model did not recognize my hand, and it was only recognized after walking about 1.5 meters. Is there any solution

Hello, this is the video I recorded. When my hand was far away, the model did not recognize my hand, and it was only recognized after walking about 1.5 meters. Is there any solution
Screenrecorder-2020-01-07-18-19-51-343.zip
@mgyong

Hi, we tried on our side and the detector should work better than 1.5 meters in usual cases. Maybe the mix of the lighting/background/hand color makes it perform poorly in your case. But anyway the detector has limitations on detecting small hands, we experimented before with larger model size and more number of anchors but it gives us a lot more false positive without much gain.

Feel free to re-open if you have further questions.

@fanzhanggoogle thank you

Hi @fanzhanggoogle
Are there any parameters that could be potentially tuned to detect smaller hands? (To be more accurate, hands that are far away)
As in the issue here, I want to detect hands which are about 1.2m away, but I'm getting a lot of false positives. I want to reduce the number of false positives. I dont mind if the hand is missed in a few cases, but I wish to minimize false detections to a very low value.
I've changed the confidence to a higher value, but I was wondering if any other parameters could be tuned.
Thanks!


New version: Baidu.BaiduNetdisk version 7.37.0

This pull request is automatically generated by 🥟 Dumplings in #3158
Microsoft Reviewers: Open in CodeFlow

@wingetbot run


[FEATURE] request new kop version release

Hello, pulsar 3.0.1 and 3.1.0 had published, is there some plan for Adapting them?

StreamNative switched the KoP release to the private versions recently. For the open sourced version, I might add a workflow for releasing them soon.

Is it means that the kop will not maintained for the open source version?

The open source version will still be maintained but recently we don't have much time on it.

If you're going to use the latest releases, you can pull the streamnative/sn-pulsar image. For example,
docker pull streamnative/sn-pulsar:<IP_ADDRESS>
docker pull streamnative/sn-pulsar:<IP_ADDRESS>

If you don't want to use the image directly, you can copy the NAR file from /pulsar/protocols directory from the container.

I'm using apache' binary, is it compatible with sn-pulsar's nar file?

Yes, it follows the rule here: https://github.com/streamnative/kop/blob/master/docs/upgrade.md#upgrade-pulsar
i.e. KoP <IP_ADDRESS> is compatible with Apache Pulsar 3.1.0

Close it by https://github.com/streamnative/kop/releases/tag/v<IP_ADDRESS>


@scenario decorator is an overkill

Repeating full scenario phrase in feature file and then in @scenario decorator is a little cumbersome. As @bubenkoff said, that approach has few values over the implicit scenario detection.
Some of them:

assertion in scenario function (executed after scenario is run)
scenarios can be parametrized and use fixtures
So removing @scenario decorator won't work as we want to have those features.
But maybe for simple feature files without a lot of requirements we can have a @scenarios('<feature_file>`) decorator which can generate all scenarios in specific feature file?

Then it could look like:
@scenarios("my.feature")
def _(fixture_for_all_scenarios_in_that_feature):
    pass

What do you think?

i think that can be done, but with a warning that you're limiting yourself
and it can look like:
scenarios('my.feature')
so not a decorated variant, but cumulative

For my any solution which limits lines of code which I don't need is good :-)
+1 if it's possible to implement.

this is not going to happen, discussed in #89


Prevent to load RN in dependencies NPM

:tada: This PR is included in version 1.5.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Appium Inspector Fails to Connect to Flutter App Due to Dynamically Changing Dart Observatory URL

I'm using Appium Inspector to automate testing of a Flutter app on an Android emulator. However, I keep encountering an issue where the Dart Observatory URL dynamically changes each time I launch the app, causing the session to fail with the following error:

Error Failed to create session. An unknown server-side error occurred while processing the command. Original error: Cannot connect to the Dart Observatory URL ws://<IP_ADDRESS>:41145/JbqYpXh-u2E=/ws. Check the server log for more details
Context: Platform: Android Emulator Appium Version: 2.11.3 Flutter Version:3.24.0

What I’ve Tried: Port Forwarding: I've manually forwarded the dynamic Dart Observatory port to a static port using:
cmd :
adb forward tcp:3000 tcp:[DYNAMIC_PORT]
This works temporarily, but since the Dart VM service port changes every time the app restarts, I have to repeat this process constantly.
Setting a Static Port: I don't have access to the source code, so I'm unable to modify the Dart VM settings to use a static port.
My Questions: ->Is there a way to stabilize the Dart Observatory port without access to the app's source code? ->Can Appium be configured to automatically detect and handle the dynamic Dart VM port? A->re there alternative approaches or tools that might handle Flutter app testing more reliably in this scenario? ->Any guidance on how to consistently connect Appium to the Dart Observatory URL or alternative solutions would be greatly appreciated!

Could you share the full Appium server log?
Usually this driver scans the observatory port in the settings and configures the port-forwarding internally.


Setting 3D gravity vector during runtime disables it instead

Godot version:
3.1.1
OS/device including version:
Ubuntu 18.04
Issue description:
Calling PhysicsServer.area_set_param to update a world's gravity vector seems to disregard the provided value, instead setting it to 0. After some digging, I found this behaviour consistent with commit https://github.com/godotengine/godot/commit/d250ade37b1e74dd11c870be279318ba01a8ba70 (link kindly provided by a user in IRC), and I can confirm that the gravity vector behaves as expected after reverting the commit. However I am not sure if doing so reintroduced whatever bug it was fixing, thus this is not a pull request.
Steps to reproduce:

Add Camera and RigidBody (any shape works, needs some visible geometry as child node).
Extend RigidBody node with a script, and set world gravity vector within _process (to anything other than 0).
Play the project.

Minimal reproduction project:
NoGravity.zip

cc @AndreaCatania


xUnit and vNext is found but not executed/run

If you follow e.g. this http://xunit.github.io/docs/getting-started-dnx.html the runner in ReSharper finds the tests, but does not execute them. Result is: Inconclusive: Test not run
ReSharper 9.2

I am having the same exact issue.  Any updates on this?

It looks for a DLL at artifacts\bin\{project}\{project}.dll, but it resides in {project}\bin\debug\{framework}

dnx . test (beta5) does work from the test project folder.

Issue still exists
I believe fix is simple: just update TestEnvironment class and take in account "{framework}"
Does it make sense to make Assembly path template configurable?

Any update on this issue? This completely blocks us from user the Resharper runner and NCover on .Net vNext

Sorry, this requires a change in ReSharper. It was originally going to happen in 10.0, but it's not made it. Next release hopefully. And it shouldn't stop you using ncover - that's not a resharper thing.

Thanks for the update. Also, I meant dotCover not NCover - I blame fast typing.

I get this on resharper <IP_ADDRESS> xUnit.net Test Support 2.3.2, specifically: "Unit Test Runner failed to run tests" "Unable to run xUnit.net tests - File not found: (projectDir)\artifacts\bin(project)(project).dll . If I enable project properties -> build -> produce outputs on build, then dll gets wrote to (path can change per build/framework settings) (projectDir)\artifacts\bin(project)\Debug\dnxcore50. If I change the "run tests from" option in resharper to this folder it instead gives me an error about not able to find xunit.dll.

This issue probably just needs to be merged into https://github.com/xunit/resharper-xunit/issues/38

Closing in favour of #38


minor refinements in comments, javadocs and other cosmetic issues rel…

…ated to availability sets and networks

Can one of the admins verify this patch?


not uplloading correctly?

hi,  seams the log agent isn't uploading correctly...
its not sending my data to inara.
i put in a inara API key thing, and i play ED and its not uploading my system or material changes...
i do something wrong?

Hi! Let's see what might have gone wrong.
Have you clicked "Validate" after inputting your INARA key?

The API key field must start glowing green after that (like on screenshot) and the checkbox must be ticked.
After you made sure it's green and the 'validated' checkbox is ticked (it ticks automatically if API key is correct), please make sure to save the settings (press OK). Then, open the settings again and press "upload latest 5 files" on "General" tab

After waiting for 10-20 seconds, open INARA and check if that helped
If that does not work, please send me ELA log. It is located in %appdata%\EliteLogAgent\Log (you can copy-paste that string into explorer) and I'll take a closer look

I did use the api
It uploads “intermittently”
So not every jump, not every station landing, it can be more then 10 jumps before it “ticks” and uploads...
Normally not a problem unless I’m doing engineering and need the materials to update while I’m in planet and it won’t do it
So, it’s “kinda” working

On 1 Nov 2018, at 6:46 am, Oleg V. Kozlyuk<EMAIL_ADDRESS>wrote:
Hi! Let's see what might have gone wrong.
Have you clicked "Validate" after inputting your INARA key?
The API key field must start glowing green after that (like on screenshot) and the checkbox must be ticked.
After you made sure it's green and the 'validated' checkbox is ticked (it ticks automatically if API key is correct), please make sure to save the settings (press OK). Then, open the settings again and press "upload latest 5 files" on "General" tab
After waiting for 10-20 seconds, open INARA and check if that helped
If that does not work, please send me ELA log. It is located in %appdata%\EliteLogAgent\Log (you can copy-paste that string into explorer) and I'll take a closer look
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

That sounds strange. if it works, it must upload INARA data every 30 seconds.
Can you attach a few logs as per my comment above?

I think I start to understand what the issue is. Are your materials spent on engineering not updated, until some time after?

Closing as the issue is probably resolved by now


Test files

Added test files - just the code this time. Also had to refactor the test dir quickly.
Just a note, tests won't pass right now since the other code files and test data hasn't been added yet.

closing as already done in recut


Added "Select last used data source" to query view

We at Underdog.io are loving redash for setting up internal dashboards. We have 1 minor pain point which is redash:metadata is always selected as the first data source for a new query. While we could delete the redash:metadata, it would be really kicking the can down the road and not solving the problem.
We had an idea to re-use the selection that a user had from the last time they change the data source (e.g. if I use "db-a", then I will see "db-a" selected the next time I create a new query). This PR is working solution for that. In this PR:

Added load/save last_selected_data_source_id in localStorage as part of dataSourceId interactions

Notes:
I am not too familiar with Angular so I wasn't sure if localStorage should be injected as a dependency. If you have any requests for how the code should be organized or about using library (e.g. ded/kizzy), please let me know.

This is so great and much needed. Thanks!
Two small things:

I try to use camelCasing for the frontend stuff (aside from objects that come back from the server). So let's use lastSelectedDataSourceId as the key for localStorage.
It's a rare edge case, but the data source might not exist anymore so worth checking that it does (you can use _.some function for that).

Sure thing, taking a look at adding those now.

Alright, the PR has been updated to use lastSelectedDataSourceId and handle non-existant data sources.

Merged. Thanks!

Awesome, thanks for the quick turnaround =)


Stuck waiting for my transaction to be mined

Starting with a clean IndexedDB, trying to leech a file, run locally with SC_ENV=virtual-funding. Metamask notification comes up showing a successful transaction.

web3torrent.Wed, 27 May 2020 18_42_39 GMT.43d68cc28.0xbded65888A0E0796545cB0EcfA2b91863A0c6E35.pino.log

Just to be clear, this is reproduced by opening web3torrent by hand, and not by running an integration test?

Just to be clear, this is reproduced by opening web3torrent by hand, and not by running an integration test?

Yes. Hub, wallet, and w3t are run with SC_ENV=virtual-funding. The seeder successfully uploads the file (and opens a channel with the hub).

I've been unable to repro this locally using SC_ENV=virtual-funding, putting this on the backburner for now and will investigate it if it pops up locally for me.

I ran into this locally and the event fired seems that there's too much ETH deposited:
assetHolder[0] event
{time:<PHONE_NUMBER>207, level: 30, module: "chain", event: {…}}
event:
address: "0x4ad3F07BEFDC54511449A1f553E36A653c82eA57"
args: Array(3)
0: "0xf863a8e375701d9a582ac6439cf0c78014b800890d3231c2a7db42c5e2988f7c"
1: BigNumber {_hex: "0x3b9aca00", _isBigNumber: true}
2: BigNumber {_hex: "0x77359400", _isBigNumber: true}
amountDeposited: BigNumber {_hex: "0x3b9aca00", _isBigNumber: true}
destination: "0xf863a8e375701d9a582ac6439cf0c78014b800890d3231c2a7db42c5e2988f7c"
destinationHoldings: BigNumber {_hex: "0x77359400", _isBigNumber: true}
length: 3
__proto__: Array(0)
blockHash: "0xc3d28f3ec84204e46c16a90a8ca033e24a78c1ee66da22accff930543c80f7b6"
blockNumber: 24
data: "0x000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000000000000000000000000000000000000077359400"
decode: ƒ (data, topics)
event: "Deposited"
eventSignature: "Deposited(bytes32,uint256,uint256)"
getBlock: ƒ ()
getTransaction: ƒ ()
getTransactionReceipt: ƒ ()
logIndex: 0
removeListener: ƒ ()
removed: false
topics: (2) ["0xb39477ecc06c5293391f8b73168b655d9c1310af93dbbf043187d79f881bbb8f", "0xf863a8e375701d9a582ac6439cf0c78014b800890d3231c2a7db42c5e2988f7c"]
transactionHash: "0xc78cb10c3734139f151790d3cdc8fe7ddc3de31cbc42f948d3425abb50a1ef10"
transactionIndex: 0
__proto__: Object
level: 30
module: "chain"
time:<PHONE_NUMBER>207
__proto__: Object

Just reproduced this on production. It looks like the chainview query doesn't return the latest amount.
trans-not-detected-web3torrent.Fri, 29 May 2020 16_26_48 GMT.50e77c3f8.0xa4988d69E40AFf5695C133952cac8A36606438dD.pino.log

The particular issue looks like the query to the chain returns a stale amount. The event from the contract gets fired and on the event we see a destinationHolding value of 0x77359400
 {"time":1590769395584,"level":30,"module":"chain","event":{"blockNumber":7993382,"blockHash":"0x98fc8a6d3ebfea7e687cfe9621a4d50d0cc45302fc6b649b45d3b48bb0d91fa7","transactionIndex":12,"removed":false,"address":"0x9aca3C3Eca5FD2D0D8De18D0F079FefdeBa837de","data":"0x000000000000000000000000000000000000000000000000000000003b9aca000000000000000000000000000000000000000000000000000000000077359400","topics":["0xb39477ecc06c5293391f8b73168b655d9c1310af93dbbf043187d79f881bbb8f","0xf19a0bc4165b6154d57f77bfeaba4a9482a7eebd85a5ecdddd5d14d64964e243"],"transactionHash":"0xb726da84d2f5466f65133b0072f65a8c39b063b392ad8ce07897f8c90f792b8b","logIndex":7,"event":"Deposited","eventSignature":"Deposited(bytes32,uint256,uint256)","args":["0xf19a0bc4165b6154d57f77bfeaba4a9482a7eebd85a5ecdddd5d14d64964e243",{"_hex":"0x3b9aca00","_isBigNumber":true},{"_hex":"0x77359400","_isBigNumber":true}]},"msg":"assetHolder[0] event","name":"xstate-wallet"}
However the "chain view" query (which calls await ethAssetHolder.holdings(channelId);) is returning a holding amount of 0x3b9aca00
{"time":1590769395960,"level":30,"module":"chain","amount":{"_hex":"0x3b9aca00","_isBigNumber":true},"channelStorage":{"turnNumRecord":{"_hex":"0x00","_isBigNumber":true},"finalizesAt":{"_hex":"0x00","_isBigNumber":true}},"finalized":false,"blockNum":{"_hex":"0x79f826","_isBigNumber":true},"msg":"Chain query result","name":"xstate-wallet"}

One possible issue is that we construct a new Contract when performing the chain query (see https://github.com/statechannels/monorepo/blob/b2aaa7dd3a6ccc4a0c4cf4688696674d982bcbd5/packages/xstate-wallet/src/chain.ts#L374). In theory I think that should work but there might be some caching issues under the covers.
I think the next steps are:

Try using existing Contracts instead of constructing new ones
Create an issue in the ethers repo to get feedback/insight.

). In theory I think that should work but there might be some caching issues under the covers.
I think the next steps are:

Try using existing Contracts instead of constructing new ones
Create an issue in the ethers repo to get feedback/insight.

I believe that https://github.com/statechannels/monorepo/issues/2031 is another example of this.
The failure referenced there was at 17d737a37d6216014148a54a3808abd4b84175a4, which has 81ae979f8c374640b942181f304d5e6cedbd045e in its history.
If we can confirm that #2031 is a duplicate of this issue, then I think that rules out the "Using new contracts causes stale chain data"
A BehaviourSubject for the chain feed would be a better solution: you would still have to fetch the chain data once, to populate the initial value, but after that, the latest known chain data would always be available.

I believe that #2031 is another example of this.
The failure referenced there was at 17d737a, which has 81ae979 in its history.
If we can confirm that #2031 is a duplicate of this issue, then I think that rules out the "Using new contracts causes stale chain data"

I've taken a quick look at the logs and one thing different from normal failures is that I don't see the Deposited event get logged out from the wallet here
In the error case I've seen we see the Deposited event fire but then the query to the chain seems to return a stale result.

A BehaviourSubject for the chain feed would be a better solution: you would still have to fetch the chain data once, to populate the initial value, but after that, the latest known chain data would always be available.

I'm not sure that a BehaviourSubject would fix the case where the Deposited event fires but the chain query returns stale data.
We can probably avoid the "stale data" being returned from a query by simply relying on the data from the event instead of performing a query to the chain. That may not affect #2031 though.

A BehaviourSubject for the chain feed would be a better solution: you would still have to fetch the chain data once, to populate the initial value, but after that, the latest known chain data would always be available.

I'm not sure that a BehaviourSubject would fix the case where the Deposited event fires but the chain query returns stale data.
We can probably avoid the "stale data" being returned from a query by simply relying on the data from the event instead of performing a query to the chain. That may not affect #2031 though.

Oh, I didn't realize that chain.ts doesn't get data from the events :(

I believe that #2031 is another example of this.
The failure referenced there was at 17d737a, which has 81ae979 in its history.
If we can confirm that #2031 is a duplicate of this issue, then I think that rules out the "Using new contracts causes stale chain data"

I've taken a quick look at the logs and one thing different from normal failures is that I don't see the Deposited event get logged out from the wallet here
In the error case I've seen we see the Deposited event fire but then the query to the chain seems to return a stale result.

I believe that the timestamps are relatively believable, since it's the same system time. So, maybe in this case

the deposit happened
then, the workflow started listening for deposits, starting with a getChainInfo call

and (2) happened after (1) -- meaning it didn't notice the deposited event -- but too soon after (1) -- meaning getChainInfo doesn't yet reflect the deposit.

I believe that the timestamps are relatively believable, since it's the same system time. So, maybe in this case

the deposit happened
then, the workflow started listening for deposits, starting with a getChainInfo call

and (2) happened after (1) -- meaning it didn't notice the deposited event -- but too soon after (1) -- meaning getChainInfo doesn't yet reflect the deposit.

One thing to note is that we've added logging for any assetHolder events that gets wired up when the chain is initialized (at start up). So we should always see a log entry for the Deposited event regardless of whether a workflow is using the feed or not.
So I'd still expect to see a Deposited event log entry which I don't see in the logs.

Well, it's starting to look like https://github.com/statechannels/monorepo/issues/1803 is more urgent.

@andrewgordstewart has a quickfix for this, where we re-query the chain after waiting a while. We should merge this for launch.


fix(ci): correctly detect forks

Description

Main PR for https://github.com/n0-computer/iroh/pull/1326.
Closes https://github.com/n0-computer/iroh/issues/1297.
Notes & open questions

Change checklist

[ ] Self-review.
[ ] Documentation updates if relevant.
[ ] Tests if relevant.

Seems to be ok now.


Implement {DataFrame,Series}.mask()

Implement {DataFrame,Series}.mask()

Close as can be implemented in a same PR with #1338.


nodeCache gets cleared with every edit in a file, resulting in slow didChange events on larger code bases

https://github.com/sumneko/lua-language-server/blob/d9fe11277e76caa2bf38292efe2df68ec1d43d10/script/vm/node.lua#L481
Right now, during a document/didChange event, files.onWatch("version") is called, which clears the whole nodeCache.
This means that every edit in a document clears the cache, which makes completion slow in a code base of about 2000 files.
If I remove the clearing, then everything is fast.
Is there a better way to clear the nodeCache partially?

I can consider adding a setting that delays resetting the cache, sacrificing some correctness for performance.

I don't fully understand this part of the code, but can't we clear the nodeCache for every key where guide.get_uri(k) == uri?
Instead of invalidating the whole cache?

So at the end of node.lua:
files.watch(function (ev, uri)
    if ev == 'version' then
        if ws.isReady(uri) then
          for source, _ in pairs(vm.nodeCache) do
            if guide.getUri(source) == uri then
              vm.nodeCache[source] = nil
            end
          end
        end
    end
end)

To give more context about my performance issue:
I have a library loaded that contains the global vim.
In an empty file, I start typing vim to get completion.
Editing the empty file, constantly clears the complete nodeCache, so everything reated to the global vim from the library needs to be rebuilt constantly, while those files never change.
Alternatively, we could just clear the roots?
files.watch(function (ev, uri)
    if ev == 'version' then
        if ws.isReady(uri) then
          local root = guide.getRoot(uri)
          for source, _ in pairs(vm.nodeCache) do
            if guide.getRoot(source) == root then
              vm.nodeCache[source] = nil
            end
          end
        end
    end
end)

I assume this would only clear the nodeCache related to a workspace folder or library if a file inside actually changed?

Added a PR #1603 that fixes this

node may contains objects of another file, so it cannot be cleared according to the uri of node.
Global varaibles are compiled by another system in script/vm/global.lua, it will not be cleared until the file is edited.
Could you please provide a demo project about you performance issue, it may be caused by some other bugs.

Some more details:
The problem seems to be caused by this types file https://github.com/folke/lua-dev.nvim/blob/main/types/vim.lua
https://github.com/folke/lua-dev.nvim/blob/main/types and the NEOVIM runtime are both added to the workspace libraries.
When worksapce libraries is small, there is no performance issue. Completion of vim. is always fast.
When I add a bunch of additional folders as workspace libraries (Neovim plugins), completion of vim. starts to become very slow.
Of course, all those plugins also use the global vim in a lot of places.
With all the plugins in the workspace library, but without  the types file, things are also fast.
I can reduce the types file to just vim=require("vim.uri") and things are slow again.

Did you find any warning in server log, like global-manager getFields cost/global-manager getGlobals cost/local-id getFields takes ?

@sumneko nope. I even have a git stash laying around that implements a global field cache and global global cache, but it honestly doesn't seem to make a difference.
not clearing the nodeCache does make a huge difference.
If you say globals are handled by vm.globals, does this mean clearing or not clearing the nodeCache should not make a difference in this case?

Just ran with your extra logging, and still nothing. The globals script is not the issue I think.
It's the didChange events that take a long time.

[19:14:39.924][warn] [#0:script/proto/proto.lua:171]: Method [textDocument/didChange] takes [1.315]sec. {
  jsonrpc = "2.0",
  method = "textDocument/didChange",
  params = {
    contentChanges = { {
        range = {
          end = {
            character = 8,
            line = 14
          },
          start = {
            character = 8,
            line = 14
          }
        },
        rangeLength = 0,
        text = "."
      } },
    textDocument = {
      uri = "file:///home/folke/dot/config/nvim/lua/plugins/treesitter.lua",
      version = 16
    }
  }
}
[19:14:39.928][warn] [#0:script/provider/provider.lua:591]: Completion takes 1.318 sec.
[19:14:39.929][warn] [#0:script/proto/proto.lua:171]: Method [textDocument/completion] takes [1.319]sec. {
  id = 12,
  jsonrpc = "2.0",
  method = "textDocument/completion",
  params = {
    context = {
      triggerCharacter = ".",
      triggerKind = 2
    },
    position = {
      character = 9,
      line = 14
    },
    textDocument = {
      uri = "file:///home/folke/dot/config/nvim/lua/plugins/treesitter.lua"
    }
  }
}

I assume the time for completion in this case didnt take 1.319, but about 0.004 seconds instead?  The logging is wrong because of the async and completion is waiting till the didChange finished?

Sorry, I need to catch the train tomorrow to take a holiday.
I will continue to check this issue after a week.

@sumneko same thing here. Also leaving on a holiday weekend 😄
I'll continue debugging this next week and see if I can find something.
Have a great weekend!

Ah, I mean 7 days ~

@sumneko no worries. Enjoy your holiday!

Could you please provide a demo, I can try to debug it.

I found what caused the issue.
This file is just used for types and builds the global vim object.
https://github.com/folke/lua-dev.nvim/blob/a37b9ba11a4d1ed97284b416526e6251d23d58e1/types/vim.lua#L24
The slow-down is caused by this line
https://github.com/neovim/neovim/blob/edc8a1f04631b021f9c5e79f7162e34f7c3299db/runtime/lua/vim/shared.lua#L9
If I remove that line, everything is fast.
Not sure what a proper way would be to fix this.

They added that line to prevent some errors by luacheck.
In other files they do local vim = assert(vim), which causes a similar slow-down.

I just submitted a PR to fix this on the Neovim end: https://github.com/neovim/neovim/pull/20551

Thank you, I will further investigate why this writing method causes performance issues.

Unfortunately, I can't reproduce this problem.
Can you provide a complete demo project?

I'm trying to assemble a demo project, but I can't reproduce it that way. I really don't get it.

this .luarc.json is slow when trying to complete `vim.api` or other

{
  "$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
  "runtime": {
    "version": "LuaJIT",
    "path": [
      "lua/?.lua",
      "lua/?/init.lua"
    ],
    "pathStrict": false
  },
  "workspace": {
    "ignoreDir": [
      "plugins",
      "types",
      "runtime",
      "workspace"
    ],
    "library": [
      "/home/folke/.local/share/bob/v0.8.0/nvim-linux64/share/nvim/runtime",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/Comment.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/LuaSnip",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/SchemaStore.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/animation.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-buffer",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-cmdline",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-cmdline-history",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-emoji",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-nvim-lsp",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-nvim-lsp-signature-help",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp-path",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/cmp_luasnip",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/dial.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/diffview.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/dressing.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/fidget.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/github-notifications.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/gitsigns.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/hlargs.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/hop.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/incline.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/indent-blankline.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/lualine.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/mason-lspconfig.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/mason.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/middleclass",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/mini.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/neo-tree.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/neogen",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/neogit",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/neorg",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/neoscroll.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nui.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/null-ls.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-autopairs",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-bufferline.lua",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-cmp",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-colorizer.lua",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-dap",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-dap-ui",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-lspconfig",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-navic",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-notify",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-scrollbar",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-spectre",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-surround",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-terminal.lua",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-toggleterm.lua",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-treehopper",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-treesitter",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-treesitter-refactor",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-treesitter-textobjects",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-treesitter-textsubjects",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-ts-context-commentstring",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/nvim-web-devicons",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/octo.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/one-small-step-for-vimkind",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/packer.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/playground",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/plenary.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/refactoring.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/rust-tools.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/specs.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/sqlite.lua",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/symbols-outline.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/telescope-file-browser.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/telescope-fzf-native.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/telescope-z.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/telescope.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/typescript.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/vim-illuminate",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/vim-matchup",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/vim-startuptime",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/windows.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/opt/yanky.nvim",
      "/home/folke/.local/share/nvim/site/pack/packer/start/dashboard-nvim",
      "/home/folke/projects/lua-dev.nvim",
      "/home/folke/projects/lua-dev.nvim/types/stable",
      "/home/folke/projects/neoconf.nvim",
      "/home/folke/projects/neoconf.nvim/types",
      "/home/folke/projects/noice.nvim",
      "/home/folke/projects/notifier.nvim",
      "/home/folke/projects/persistence.nvim",
      "/home/folke/projects/todo-comments.nvim",
      "/home/folke/projects/tokyonight.nvim",
      "/home/folke/projects/trouble.nvim",
      "/home/folke/projects/twilight.nvim",
      "/home/folke/projects/which-key.nvim",
      "/home/folke/projects/zen-mode.nvim"
    ]
  }
}

copy of the same .luarc.json, but pointing to directory workspace, where I copied all the directories
{
  "$schema": "https://raw.githubusercontent.com/sumneko/vscode-lua/master/setting/schema.json",
  "runtime": {
    "version": "LuaJIT",
    "path": [
      "lua/?.lua",
      "lua/?/init.lua"
    ],
    "pathStrict": false
  },
  "workspace": {
    "ignoreDir": [
      "plugins",
      "types",
      "runtime",
      "workspace"
    ],
    "library": [
      "workspace/animation.nvim",
      "workspace/cmp-buffer",
      "workspace/cmp-cmdline",
      "workspace/cmp-cmdline-history",
      "workspace/cmp-emoji",
      "workspace/cmp-nvim-lsp",
      "workspace/cmp-nvim-lsp-signature-help",
      "workspace/cmp-path",
      "workspace/cmp_luasnip",
      "workspace/Comment.nvim",
      "workspace/dashboard-nvim",
      "workspace/dial.nvim",
      "workspace/diffview.nvim",
      "workspace/dressing.nvim",
      "workspace/fidget.nvim",
      "workspace/github-notifications.nvim",
      "workspace/gitsigns.nvim",
      "workspace/hlargs.nvim",
      "workspace/hop.nvim",
      "workspace/incline.nvim",
      "workspace/indent-blankline.nvim",
      "workspace/lua-dev.nvim",
      "workspace/lualine.nvim",
      "workspace/LuaSnip",
      "workspace/mason-lspconfig.nvim",
      "workspace/mason.nvim",
      "workspace/middleclass",
      "workspace/mini.nvim",
      "workspace/neo-tree.nvim",
      "workspace/neoconf.nvim",
      "workspace/neogen",
      "workspace/neogit",
      "workspace/neorg",
      "workspace/neoscroll.nvim",
      "workspace/noice.nvim",
      "workspace/notifier.nvim",
      "workspace/nui.nvim",
      "workspace/null-ls.nvim",
      "workspace/nvim-autopairs",
      "workspace/nvim-bufferline.lua",
      "workspace/nvim-cmp",
      "workspace/nvim-colorizer.lua",
      "workspace/nvim-dap",
      "workspace/nvim-dap-ui",
      "workspace/nvim-lspconfig",
      "workspace/nvim-navic",
      "workspace/nvim-notify",
      "workspace/nvim-scrollbar",
      "workspace/nvim-spectre",
      "workspace/nvim-surround",
      "workspace/nvim-terminal.lua",
      "workspace/nvim-toggleterm.lua",
      "workspace/nvim-treehopper",
      "workspace/nvim-treesitter",
      "workspace/nvim-treesitter-refactor",
      "workspace/nvim-treesitter-textobjects",
      "workspace/nvim-treesitter-textsubjects",
      "workspace/nvim-ts-context-commentstring",
      "workspace/nvim-web-devicons",
      "workspace/octo.nvim",
      "workspace/one-small-step-for-vimkind",
      "workspace/packer.nvim",
      "workspace/persistence.nvim",
      "workspace/playground",
      "workspace/plenary.nvim",
      "workspace/refactoring.nvim",
      "workspace/runtime",
      "workspace/rust-tools.nvim",
      "workspace/SchemaStore.nvim",
      "workspace/specs.nvim",
      "workspace/sqlite.lua",
      "workspace/stable",
      "workspace/symbols-outline.nvim",
      "workspace/telescope-file-browser.nvim",
      "workspace/telescope-fzf-native.nvim",
      "workspace/telescope-z.nvim",
      "workspace/telescope.nvim",
      "workspace/todo-comments.nvim",
      "workspace/tokyonight.nvim",
      "workspace/trouble.nvim",
      "workspace/twilight.nvim",
      "workspace/types",
      "workspace/typescript.nvim",
      "workspace/vim-illuminate",
      "workspace/vim-matchup",
      "workspace/vim-startuptime",
      "workspace/which-key.nvim",
      "workspace/windows.nvim",
      "workspace/yanky.nvim",
      "workspace/zen-mode.nvim"
    ]
  }
}

The second one is from the demo project I'm creating for you to test. It has a subdirectory workspace and then a copy of every directory from the first file.
But what is super weird is that completion is instant in the demo project! I honestly don't understand how this can be the case. Same amount of files, same library. Only difference is the demo project has a copy of the original files. I'm a bit at loss here :)
Any ideas?

I'm able to reproduce it! Please see https://github.com/folke/lua-language-server/tree/perf_demo_project
If you open the file test.lua in the git root, and try to complete first vim. and then vim.api. you'll see that everything is fast.
If you open the file test/test.lua, in the test directory (so test as rootdir and test/.luarc.json as config file), then you'll see that it is all very slow.
Both .luarc.json files point to the same directories under /workspace.

It is caused by #1592
This PR leads to frequently scan all files (about 3,000) and cross -compare their file names.

I don't think it's related to #1592, since this happens with pathStrict=false, so that code path ran anyway.

Just to clarify. The following configurations have the same amount of files / workspace folders, but results are fast in the first one and slow in the second one:

rootdir=/demo_project/ config=/demo_project/.luarc.json
rootdir=/demo_project/test/ config=/demo_project/test/.luarc.json

@sumneko the PR prevents looping over the files when pathStrict=true.
In that case, completions are super fast now with both root dirs :)


[BUG] ROCm: the cupy.cuda.cub module cannot be built in v8

Looks like in CuPy v8 we assumed the cupy.cuda.cub module is always built, but the ROCm support was not added until recently (#4027), so an error is raised upon import cupy:
$ pip install -v cupy    # build from sdist
$ python -c "import cupy"
Traceback (most recent call last):
  File "/home/leofang/miniconda3/envs/cupy_test/lib/python3.7/site-packages/cupy/__init__.py", line 20, in <module>
    from cupy import core  # NOQA
  File "/home/leofang/miniconda3/envs/cupy_test/lib/python3.7/site-packages/cupy/core/__init__.py", line 1, in <module>
    from cupy.core import core  # NOQA
  File "cupy/core/core.pyx", line 1, in init cupy.core.core
  File "cupy/core/_routines_manipulation.pyx", line 1, in init cupy.core._routines_manipulation
  File "cupy/core/_routines_indexing.pyx", line 1, in init cupy.core._routines_indexing
  File "cupy/core/_routines_math.pyx", line 6, in init cupy.core._routines_math
  File "cupy/core/_reduction.pyx", line 1, in init cupy.core._reduction
  File "cupy/core/_cub_reduction.pyx", line 1, in init cupy.core._cub_reduction
ModuleNotFoundError: No module named 'cupy.cuda.cub'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/leofang/miniconda3/envs/cupy_test/lib/python3.7/site-packages/cupy/__init__.py", line 41, in <module>
    raise ImportError(_msg) from e
ImportError: CuPy is not correctly installed.

If you are using wheel distribution (cupy-cudaXX), make sure that the version of CuPy you installed matches with the version of CUDA on your host.
Also, confirm that only one CuPy package is installed:
  $ pip freeze

If you are building CuPy from source, please check your environment, uninstall CuPy and reinstall it with:
  $ pip install cupy --no-cache-dir -vvvv

Check the Installation Guide for details:
  https://docs.cupy.dev/en/latest/install.html

original error: No module named 'cupy.cuda.cub'

I think this can be fixed simply by backporting #4027.
ref: https://stackoverflow.com/questions/64613606/cupy-on-amd-gpu-causing-an-importerror

Thanks! Fixed by backporting #4027 (+ #4162).
Will add test in https://github.com/cupy/cupy/pull/4326.

Thanks @kmaehashi @emcastillo!

Hi @leofang ！I encountered this problem on ROCM 3.9. I read the messages in #4027 , but still not very clear about how this problem was solved. Is the solution merged in any released version of CuPy? I tested v8.1.0, v8.2.0 and v9.0.0a2 on ROCM 3.9 and all of these tests failed due to this problem.

@ipe-zhangyz, this is fixed in v8.2 (#4327) and should just work in v9.x (the master branch). Did you install hipcub and rocprim? They are part of the ROCm libraries but are optional packages, not installed by default when you install the meta package. See the installation guide: https://docs.cupy.dev/en/stable/install_rocm.html.

Hello, @leofang , I have hipcub and rocprim installed. And I checked out the master branch of cupy and reinstalled it, unfortunately, the problem still exists:
Traceback (most recent call last):
  File "/home/zhangyz/software/miniconda3/envs/cupy_rocm39/lib/python3.8/site-packages/cupy/__init__.py", line 20, in <module>
    from cupy import core  # NOQA
  File "/home/zhangyz/software/miniconda3/envs/cupy_rocm39/lib/python3.8/site-packages/cupy/core/__init__.py", line 1, in <module>
    from cupy.core import core  # NOQA
  File "cupy/core/core.pyx", line 1, in init cupy.core.core
  File "/home/zhangyz/software/miniconda3/envs/cupy_rocm39/lib/python3.8/site-packages/cupy/cuda/__init__.py", line 34, in <module>
    from cupy.cuda import cub  # NOQA
ImportError: cannot import name 'cub' from partially initialized module 'cupy.cuda' (most likely due to a circular import) (/home/zhangyz/software/miniconda3/envs/cupy_rocm39/lib/python3.8/site-packages/cupy/cuda/__init__.py)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "elementwise.py", line 2, in <module>
    import cupy as cp
  File "/home/zhangyz/software/miniconda3/envs/cupy_rocm39/lib/python3.8/site-packages/cupy/__init__.py", line 41, in <module>
    raise ImportError(_msg) from e
ImportError: CuPy is not correctly installed.

If you are using wheel distribution (cupy-cudaXX), make sure that the version of CuPy you installed matches with the version of CUDA on your host.
Also, confirm that only one CuPy package is installed:
  $ pip freeze

If you are building CuPy from source, please check your environment, uninstall CuPy and reinstall it with:
  $ pip install cupy --no-cache-dir -vvvv

Check the Installation Guide for details:
  https://docs.cupy.dev/en/latest/install.html

original error: cannot import name 'cub' from partially initialized module 'cupy.cuda' (most likely due to a circular import) (/home/zhangyz/software/miniconda3/envs/cupy_rocm39/lib/python3.8/site-packages/cupy/cuda/__init__.py)

In the log file generated by pip install cupy --no-cache-dir -vvvv, there are logs like this:
    Build Environment:
      Include directories: ['/opt/rocm-3.9.1/include/hipcub', '/tmp/pip-req-build-63l97x26/install/../cupy/core/include', '/opt/rocm-3.9.1/include', '/opt/rocm-3.9.1/include/hip', '/opt/rocm-3.9.1/include/rocrand', '/opt/rocm-3.9.1/include/roctracer']
      Library directories: ['/opt/rocm-3.9.1/lib']
      nvcc command       : (not found)
...........
    Modules:
      cuda      : Yes
      cub       : No (version 201005)
        -> nvcc command could not be found in PATH.
        -> Check your PATH environment variable.
      nccl      : Yes (version 2708)
      thrust    : No
        -> nvcc command could not be found in PATH.
        -> Check your PATH environment variable.

    WARNING: Some modules could not be configured.
    CuPy will be installed without these modules.
    Please refer to the Installation Guide for details:
    https://docs.cupy.dev/en/stable/install.html
........................
 copying cupy/core/include/cupy/cub/cub/block/block_radix_sort.cuh -> build/lib.linux-x86_64-3.8/cupy/core/include/cupy/cub/cub/block
  copying cupy/core/include/cupy/cub/cub/block/block_histogram.cuh -> build/lib.linux-x86_64-3.8/cupy/core/include/cupy/cub/cub/block
  copying cupy/core/include/cupy/cub/cub/block/block_store.cuh -> build/lib.linux-x86_64-3.8/cupy/core/include/cupy/cub/cub/block
..................
 Compiling cupy/core/_cub_reduction.pyx because it changed.
................
 [ 4/52] Cythonizing cupy/core/_cub_reduction.pyx
.................
  building 'cupy.core._cub_reduction' extension
  gcc -pthread -B /home/zhangyz/software/miniconda3/envs/cupy_rocm39/compiler_compat -Wl,--sysroot=/ -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -D_FORCE_INLINES=1 -DCUPY_USE_HIP=1 -D__HIP_PLATFORM_HCC__=1 -DCUPY_CUB_VERSION_CODE=201005 -I/opt/rocm-3.9.1/include/hipcub -I/tmp/pip-req-build-63l97x26/install/../cupy/core/include -I/opt/rocm-3.9.1/include -I/opt/rocm-3.9.1/include/hip -I/opt/rocm-3.9.1/include/rocrand -I/opt/rocm-3.9.1/include/roctracer -I/home/zhangyz/software/miniconda3/envs/cupy_rocm39/include/python3.8 -c cupy/core/_cub_reduction.cpp -o build/temp.linux-x86_64-3.8/cupy/core/_cub_reduction.o -std=c++11
  cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++
..............
copying build/lib.linux-x86_64-3.8/cupy/core/_cub_reduction.cpython-38-x86_64-linux-gnu.so -> build/bdist.linux-x86_64/wheel/cupy/core
...............
 copying build/lib.linux-x86_64-3.8/cupy/core/include/cupy/cub/cub/util_type.cuh -> build/bdist.linux-x86_64/wheel/cupy/core/include/cupy/cub/cub
  creating build/bdist.linux-x86_64/wheel/cupy/core/include/cupy/cub/cub/grid
....................
 adding 'cupy/core/_cub_reduction.cpython-38-x86_64-linux-gnu.so'
.......................
 adding 'cupy/cuda/cupy_cub.cu'
....................

I'm not sure whether the cub module is built in my case, as there are some hints that conflict with each other in the log. For example, the configuration of modules says there is no cub (maybe it means no cuda cub?), but in the following compilation, there are cub relevant files compiled and dynamic libraries added.  On the same machine, the CuPy v8.0.0 works well with rocm 3.5.0. By the way, my operation system is CentOs 7.6.

@ipe-zhangyz Your error log looks specious to me. First, note that the error is different from those reported originally and on SO: yours is
ImportError: cannot import name 'cub' from partially initialized module 'cupy.cuda' (most likely due to a circular import)

whereas the original error (that we fixed now) is
ModuleNotFoundError: No module named 'cupy.cuda.cub'

I think it's suggesting either due to a dirty build, or your env vars were messed up during build time.
For example, if it used to work for you (I think you made it work for quite a while?) but now it doesn't after updating ROCm, likely you need to check your env vars like ROCM_HOME, PATH, and LD_LIBRARY_PATH and see if you include the correct paths to the new ROCm or not.
Also, this part of your log looks weird to me
    Modules:
      cuda      : Yes
      cub       : No (version 201005)
        -> nvcc command could not be found in PATH.
        -> Check your PATH environment variable.
      nccl      : Yes (version 2708)
      thrust    : No
        -> nvcc command could not be found in PATH.
        -> Check your PATH environment variable.

though in this case I can't say for sure what's wrong. Could you upload the full log generated during pip install?
Another thing to try is to clean up the source directory and rebuild. You can either start with a fresh clone of cupy, or do git clean -fdx in the existing cupy directory (WARNING⚠: this removes all files that are not part of the git repo).

Hello @leofang , thanks for your reply! As you said that there may be something wrong with my  env vars, I switched to a new machine which has not been installed with any version of CuPy to build it form source. However, the problem is the same. I build it as follows:
cd ${cupy_source_dir}
git clean -fdx
export HCC_AMDGPU_TARGET=gfx900
export __HIP_PLATFORM_HCC__
export CUPY_INSTALL_USE_HIP=1
export ROCM_HOME=/opt/rocm-3.9.1

pip install . --no-cache-dir -vvvv

Here is the log. There are some errors about cuda_runtime.h not found, which I don't know if matters.
log.LOG
the PATH var is:
/public/home/zhangyz/software/miniconda3/envs/cupy_rocm39/bin:/public/home/zhangyz/software/miniconda3/condabin:/opt/rocm-3.9.1/bin:/opt/rocm-3.9.1/hip/bin:/opt/rh/devtoolset-7/root/usr/bin:/usr/lib64/qt-3.3/bin:/public/home/zhangyz/perl5/bin:/opt/hpc/software/mpi/hpcx/v2.4.0/hcoll/bin:/opt/hpc/software/mpi/hpcx/v2.4.0/ucx/mt/bin:/opt/hpc/software/mpi/hpcx/v2.4.0/ompi/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/ibutils/bin:/public/home/zhangyz/.local/bin:/public/home/zhangyz/bin

@ipe-zhangyz Thank you. Any chance when it worked previously for you, you were on a machine with CUDA (not ROCm) installed, but now there is none? This would explain and is indeed a bug.

@leofang , the machine I used before has only ROCm installed, no CUDA. Some of my test cases used to fail before I followed your instructions. We discussed those problems here #4216 .

@ipe-zhangyz I meant previously you didn't have issues with import cupy, right? This is very odd, I don't know what's changed after your upgrade to ROCm 3.9. In CuPy's CI we currently always test building and importing against the latest ROCm.
A few more questions to help me investigate further:

Could you run hipconfig and post the output here?
Are there other versions of ROCm installed on the same system?

Thanks.

@leofang , with ROCm 3.5 and CuPy v8.0.0，I have no issue with import cupy.
Currently I have tested CuPy with ROCm 3.5 and ROCm 3.9 on two different machines, both of which have more than one version of ROCm installed. I use module (an environment variables management tool) to switch among different versions of ROCm.
I uninstalled the previous CuPy  v8.0.0 on ROCm 3.5 and reinstelled it and got this log:
log-3.5.LOG
It seems that there are some major diffenences between the installation of v9 on ROCm 3.9 and v8.0.0 on ROCm 3.5，for example, in v8.0.0, cub module is not configured, instead it is cusolver that is configured:
    Modules:
      cuda      : Yes
      cusolver  : Yes
      thrust    : No
        -> nvcc command could not be found in PATH.
        -> Check your PATH environment variable.

    WARNING: Some modules could not be configured.
    CuPy will be installed without these modules.
    Please refer to the Installation Guide for details:
    https://docs.cupy.dev/en/stable/install.html

Is this the reason that there is no cub issue in v8.0.0?
Here are the outputs of hipconfig on my two machines, one of which is configured to ROCm 3.5 and the other is ROCm 3.9.
hipconfig-rocm35.LOG
hipconfig-rocm39.LOG
To be clear, the two logs are from two different machines, but both of the two machines have multiple versions of ROCm，from rocm 2.9 to  3.9,  installed in different directories, and managed using the module tool. On the machine which has both ROCm 3.5 and ROCm 3.9, the CuPy v8.0.0 works with ROCm 3.5，but v8.1.0, v8.2.0 and v9 have the cub issue with ROCm 3.9.

Thanks, @ipe-zhangyz. Your hipconfig logs seem legit.  Set
export NVCC=/something/does/not/exist

and rebuild a case in which you know import CuPy would fail? I feel I was actually very close 🤞

@leofang , do you mean to build CuPy in an environment that has only ROCm installed but has an  NVCC env var exported? I tried it as follows:
cd ${cupy_source_dir}
git clean -fdx
export HCC_AMDGPU_TARGET=gfx900
export __HIP_PLATFORM_HCC__
export CUPY_INSTALL_USE_HIP=1
export ROCM_HOME=/opt/rocm-3.9.1
export NVCC=/usr/local/cuda

pip install . --no-cache-dir -vvvv

This cannot install CuPy successfully. Here is the log.
log-ROCm39-NVCC.LOG

Thanks, @ipe-zhangyz. This is precisely the error I am looking for. I will try to work out a patch. The reason we didn't notice it so far is that our dev environments always have CUDA & ROCm GPUs coexist (for cost saving)...

Let's move the discussion to #4415.


Privacy Settings: wiping metadata

Sometimes, people may just want to share photos without revealing the information of Exif, GPS or TIFF.
Could you add an optional feature to show or wipe the metadata of photos that were published on blog?

This is currently not possible with Hugo:
While you can disable metadata in the processed files (by changing the includedFields in hugo.toml) this will not prevent the original images to be published alongside the resized/compressed ones.
Since you might want to process images for the blog anyway, e.g. resize them to the maximum size you want viewers to be able to download (in most cases, just throwing in the high-resolution originals is a waste of storage space), the removal of metadata can be done in that step.


Add additional Lifeline associations to Philio PAN 04

https://forum.iobroker.net/post/508035

Probably a configuration error


Metadata missing/Formatting issues for artwroks

current eigen beta:

current on microgravity:

We're currently missing the pricing information for artworks that have pricing info available.
It seems too that we assume that each work title will have a comma and date follow, when the work does in fact not have a date, the comma still sticks around

Worth nothing that we will want to move towards a metadata structure that looks the same as force
https://github.com/artsy/force/issues/5079


Ultimate TTT AI

Description
Adds a single-player CPU opponent with 3 difficulties:

Easy -- Plays a random move
Medium -- Plays optimally within sub-games, but has no overall strategy
Hard -- Analyzes the board and tries to play the best overall move, taking into account the best sub-game move, and weighing that against what the opponent's best move would be in the sub-game they would get to move in. Or, if they would get to pick any sub-game, their best move overall.

Also changes tttHandleGameInput() to use a slightly different method, which should prevent any squares from becoming inaccessible and I think maybe it handles a bit more intuitively than the previous one? I recommend playing with it to see. But it pretty much tries to find a close free space before it wraps all the way around by bumping the cursor away from the edge of the board, and it also prioritizes the last intended direction for the secondary cursor direction.
Test Instructions
Play against the AIs, see how they feel. See if the cursor behaves reasonably in some funky situations.
Ticket Links
Closes #267
Readiness Checklist

[x] I have run make format to format the changes
[x] I have compiled the firmware and the changes have no warnings
[x] I have compiled the emulator and the changes have no warnings
[x] I have run make cppcheck and checked that cppcheck_result.txt has no warnings for the changes
[x] I have added doxygen comments to any code used by more than one Swadge mode. This includes /*! \file comments with Design Philosophy, Usage, and Example sections for new headers.
[x] I have run make docs and checked that doxy_warnings.txt has no warnings for the new code

@dylwhich I stapled three things onto this PR (hope you don't mind):

More markers!
Randomize play order for single player
Randomize CPU marker to be an unlocked one which isn't the players

Nice, good idea! Hah, I think I might have hardcoded the Hard CPU to make the move that's most advantageous for Player 2, because it really feels like it's avoiding winning against me when it goes first

This all looks good to me (and feels good too). You can merge after addressing feedback (if you wanna)


Clear the JAVA_HOME* and ANDROID* environment variables prior to building Android app

Changes

GitHub runners bring along their own JDK and Android SDK

JAVA_HOME=/usr/lib/jvm/temurin-11-jdk-amd64
JAVA_HOME_11_X64=/usr/lib/jvm/temurin-11-jdk-amd64
JAVA_HOME_8_X64=/usr/lib/jvm/temurin-8-jdk-amd64
JAVA_HOME_17_X64=/usr/lib/jvm/temurin-17-jdk-amd64
ANDROID_SDK_ROOT=/usr/local/lib/android/sdk
ANDROID_HOME=/usr/local/lib/android/sdk
ANDROID_NDK=/usr/local/lib/android/sdk/ndk/25.2.9519653
ANDROID_NDK_LATEST_HOME=/usr/local/lib/android/sdk/ndk/25.2.9519653
ANDROID_NDK_HOME=/usr/local/lib/android/sdk/ndk/25.2.9519653

NOTE: Not all GitHub runners use the same Android SDK and JDK; for instance, Ubuntu-22.04 is exposing JDK 11 while Windows Server 2022 and macOS 12.6.5 are exposing JDK 8.
This PR clears all environment variables that start with JAVA_HOME and ANDROID so Briefcase will install and use its own Android SDK and JDK for testing.

The fact that all these environment variables are affecting the behavior of Briefcase and its underlying tools so much suggests that we may be better off running these tests in isolated environments like tox does

Tested these changes with JDK 17: https://github.com/beeware/briefcase-android-gradle-template/actions/runs/5165357682

Notes

A question hit me in the shower: "what will happen to people with JAVA_HOME already set to JDK 11?"
Well....turns out we've already been testing that all along since our CI has been using GitHub's JDK 11 install.

PR Checklist:

[x] All new features have been tested
[x] All new features have been documented
[x] I have read the CONTRIBUTING.md file
[x] I will abide by the code of conduct

A question hit me in the shower: "what will happen to people with JAVA_HOME already set to JDK 11?"
Well....turns out we've already been testing that all along since our CI has been using GitHub's JDK 11 install.

Why didn't it hit this version check? I'd expect to see that message in the recent logs, but it isn't there.

A question hit me in the shower: "what will happen to people with JAVA_HOME already set to JDK 11?"
Well....turns out we've already been testing that all along since our CI has been using GitHub's JDK 11 install.

Why didn't it hit this version check? I'd expect to see that message in the recent logs, but it isn't there.

Ahh...that's a good point. I was under the impression that it was already possible to manually specify and use a JDK 11 install with Briefcase but that check will certainly prevent that.
Therefore, we don't need to worry about anyone using JDK 11 presently...because they can't.
As for the missing error message, it's because of caching. Once Briefcase detects the JDK at JAVA_HOME isn't JDK 8, it goes to inform the user and install its own JDK. However, if Briefcase has already installed JDK 8 in to its data directory, it will skip showing the message about ignoring JAVA_HOME to the user. This is what happens in CI since we cache the Briefcase data directory.
Nonetheless, Briefcase is giving precedence to the GitHub installs of JDK and Android SDK.

For Android SDK, it is always using GitHub's install.
For JDK, it uses GitHub's install when it is a JDK 8....which is surprisingly inconsistent across GitHub's runner OSs.

I did some evaluation and testing of all this here where I printed all the environment variables, poked at the JDK at JAVA_HOME, and tried to initialize Java in Briefcase with some added logging.

What's the underlying motivation for this change? My main concern is that it will significantly slow down builds - every build will need to download the Android SDK, which... isn't small. Android builds are already painfully slow; I'd rather not make them even slower unless there's an underlying reason to do so.

What's the underlying motivation for this change?

Just to better replicate what actually happens in user installs. Although, I don't have evidence to suggest we should expect issues.

My main concern is that it will significantly slow down builds - every build will need to download the Android SDK, which... isn't small. Android builds are already painfully slow; I'd rather not make them even slower unless there's an underlying reason to do so.

That's definitely a concern. Since we're caching the Briefcase data directory, I'd hope some of that could be mitigated....although, I'm not sure if the SDK downloaded everything there.
To that end, maybe it would be better to just explicitly set JAVA_HOME to whatever is in JAVA_HOME_17_X64 so the JDK isn't downloaded either for any platform.

What's the underlying motivation for this change?

Just to better replicate what actually happens in user installs. Although, I don't have evidence to suggest we should expect issues.

Unless we're actually seeing problems, I'm inclined to ignore this change. Testing Briefcase works using Github CI configurations is a good canary (since we actively encourage the use of GitHub CI for cross-platform building); and it's a decent representation of the sort of developer configuration we're going to see in the "real world".

That's fair. This PR was mostly another "here's an idea" PR; I always intend to make this more explicit in the PR description but then don't....I'll try to make this clearer going forward.


@conda-forge-admin, please add bot automerge

@conda-forge-admin, please add bot automerge

@conda-forge-admin, please add bot automerge

Hi! This is the friendly automated conda-forge-webservice.
I just wanted to let you know that I added bot automerge in conda-forge/pytest-echo-feedstock#2.


Update discord links, lint markdown

Summary
This PR updates the discord links to use a non-expiring invite link so that users not in Reactiflux yet can join the channel. Also ran the markdown linter since many of the md files needed an update 👌
Test plan
Ran the website locally and reviewed the changes

Yay, thanks!


Configure scheduled signon rake tasks via jenkins

Part of https://trello.com/c/BrKRdn4f/495-rebuild-gov-uk-app-deployment-pipeline
Signon performs several rake tasks at regular intervals in order to
clean up certain user account specific data and fetch organisational
data. Previously this was done via the 'whenever' gem and the appropriate
cron configuration was passed from alphagov-deployment, this is going
away so we'll configure these tasks via jenkins per environment.
I'm not sure whether multiple jobs can be configured like this, given the structure of the jobs yaml file it's implied they are just an array of jobs.

I think the multiple YAML is good. Instead of running an SSH command, could we get these jobs to trigger a downstream job similar to how we do the data sync? That means we have one place which shows all the rake task history.

That's a nice idea @alexmuller, do downstream like this need to be configured within publishers config or can they be left in the builders conf? ie is publishers downstream configuration?

Thanks @alexmuller, I've updated, I'll deploy this branch to integration as I'm not 100% on the downstream config.


The VGrid has initially a height of "0" | Vue3

Hello Revolist-Community,
If I install revoGrid for Vue3 as described in your gitReadme, the started Vue3 App does not show anything cause the initial height of the VGrid is set to "0". So you need to give it a height first to see it.
Maybe you should add this info to your Readme.
Thank you, have a good time and stay healthy

Hello @BenjaminVockenberg. Thank you for your feedback.
We will add this information in the 4th version docs.
The main idea behind it to make grid as smart as any element on the page.
We believe that setting up initial height to the grid itself is old school approach which was popular in old systems but we've tried to make this grid the way so it takes size of any container around it or styles applied to it.


clusterfuzz lite

This is the initial PR for clusterfuzz lite.
There are going to be more things to come.

handle crashes data in a separate repository (so that we don't expose a vulnerability)
Include other targets
Use the existing corpus
Signed-off-by: naveen<EMAIL_ADDRESS>

@oliverchang / @jonathanmetzman  ClusterFuzzLite somehow the workflow is failing and would appreciate if you can help with this.  Here are some of the the runs https://github.com/naveensrinivasan/sigstore/actions/workflows/cflite_pr.yaml 😮💨

Awesome @naveensrinivasan  !
Could you please try this for build.sh instead: https://google.github.io/clusterfuzzlite//build-integration/go-lang/#buildsh

@bobcallaway / @dlorenc  👀  please.

Closing this because of this https://github.com/google/oss-fuzz/pull/6890#issuecomment-981801562


docs: Update tags for go/set-namespace/v0.3.0 (#803)

The target should be a release branch (in this case set-namespace/v0.3)

The target branch should be the release branch instead of master

The target should be a release branch (in this case set-namespace/v0.3)

Ah, I see. That helps. Actually in my local I used upstream/set-namespace/v0.3 since my origin and upstream have the same branch it causes the following error.  Would be great to add some user guide.
hint: If you'd like to always have checkouts of an ambiguous <name> prefer
hint: one remote, e.g. the 'origin' remote, consider setting
hint: checkout.defaultRemote=origin in your config.
fatal: 'set-namespace/v0.3' matched multiple (2) remote tracking branches


What is the proposed required java version?

1.9 or 9

What is the proposed required java version?
Background is, that the readme is pointing to Java 1.9/9, but until version 3.14 it was build using 1.7 (regarding to pom.xml) and so working in a common used Java 8 env. In 3.15 it was moved to Java 11 and now it is back to 1.9/9 (regarding to pom.xml).

so what is the issue?

For me (and may others too) versions > 3.14 does not work with Java 8 anymore, that’s why I want only to double check if this move was by purpose and could not be rolled back :-)
Because then I have to stick to version 3.14 (and may miss new features and fixes).
The readme was pointing to Java 1.9/9 at times where the library was working with Java 8 (and may 1.7/7 as well), so I assumed that this information was may not correct.

Java 1.7/7 was released a decade ago (in 2011) and so it's beyond the expanded time window for releases. Java 1.9/9 is from 2017 and is currently the actual minimum supported version (note that documentation may have said 1.9 before while you could use 1.7 but that wasn't wrong, we wanted to encourage developers to upgrade and now we're actually requiring it)

Thanks for the quick clarification!
Even if choosing a non-LTS version (like 1.9/9 or in the pom.xml 1.7) is unusual (most libraries are moving alongside the still maintained https://adoptium.net/support.html  LTS path 8, 11, …), I could understand to choose more modern versions to enable new language features :-)


Tsconfig option to disable .tsx extension lookup in module resolution

Suggestion
Running tsc --traceResolution in my project I found that Typescript was looking up .tsx files for every module resolution. That's very inconvenient, first because .tsx extension serves a very specific domain, second because by elliminating hundreds or maybe thousands of (think of a really big project) unecessary stat() syscalls the build time would probably speed up a bit, or maybe considerably.
🔍 Search Terms

tsx
module resolution

✅ Viability Checklist
My suggestion meets these guidelines:

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

came here because I noticed the same thing while debugging why references aren't resolving files properly


mapStateToProps to called during SSR

Since we bypass ever calling the react-apollo connect method, the redux methods are not called so ownProps may not be accurate if they rely on the mapStateToProps

fixed in 0.3.17


Configuration method 'getInstance()' is not found

Issue Type
[X] Question
Description and/or steps/code to reproduce the problem
I followed the instruction "how to use the osmdroid library" (https://github.com/osmdroid/osmdroid/wiki/How-to-use-the-osmdroid-library). All worked fine expect for one line of code: line 22 ->
Configuration.getInstance().load(ctx, PreferenceManager.getDefaultSharedPreferences(ctx));
throws an error:
"cannot find symbol
Configuration.getInstance().load(ctx, PreferenceManager.getDefaultSharedPreferences(ctx));
^
symbol:   method getInstance()"
without this line of code, the map is empty/unvisible on my mobile app. I also created a stackoverflow question for this: https://stackoverflow.com/questions/60848114/map-is-not-visible-in-openstreetmap-osm
Environment
Android Studio (java project, not Kotlin)
Version of osmdroid the issue relates to:
6.1.6

I don't know how up-to-date the wiki is.
My suggestion: have a look at the demo app (available in Google Play), see which demo you like, and have a look at the corresponding code (like SampleMarker.java for the "Marker" demo).

that's a bit sad I think, because this wiki is not really useful than. However I am struggeling get my App running. All I want is just to display the map on my screen (in an app). I hope you understand me. I do not really understand which classes I need for that.

I don't know how up-to-date the wiki is.
My suggestion: have a look at the demo app (available in Google Play), see which demo you like, and have a look at the corresponding code (like SampleMarker.java for the "Marker" demo).

that's a bit sad I think, because this wiki is not really useful than. However I am struggeling get my App running. All I want is just to display the map on my screen (in an app). I hope you understand me. I do not really understand which classes I need for that.

Ah I fixed it, the error was my wrong class which I imported. You have to "import org.osmdroid.config.Configuration;" not ".res.Configuration;

@MahatmaGonnDir I hope you've managed to display your first map. If I understand well it's OK to close this issue, isn't it?

@monsieurtanuki yes, you can close it. My app works now how I expect it

That's good news!


Broken for newer go versions

Describe the bug:
This package does not compile.
<EMAIL_ADDRESS>285babe68092\reflect_to.go:34:10: undefined: js.Wrapper

To reproduce:
Use any version containing this patch:
https://github.com/golang/go/commit/6c0daa733192031eab23d09ed6515c4cd959aa92
Expected behavior:
Compiles.
Additional context:
Will stay like this, so this lib has to be adjusted to work again, see https://github.com/golang/go/issues/50310

Feel free to create a PR to fix, seems relatively straightforward to fix

Wow, that was fast... Many thanks!


Clarification of the type of services and units

I proposes to clarify the type of services and units used. System services and user services are present in Systemd. The user services are completely invisible to this module. In my case, this makes the module unusable.

Hi Adam, thank you for the README update. Is it possible to use busctl introspect or gdbus introspect to inspect user services?

@jangaraj , use --user. I don't know how to introspect another user services.


Ensure requirements are clearly documented

Prior to moving into development milestone, ensure all requirements/epics have enough documentation and design is clear.
requires #12

Extension of PID - ensuring all requirements are ready to be expanded upon as/when required ahead of development.

Remains in-progress. Part of this task will be feeding in the results of the survey/feedback following input from Allan & Barrie.

Done.