Module cannot be called 'test'

It seems that a module called test is not loaded at all. There's no error message when trying to import it, which confused me for a good amount of time. If this is intended then please add an error message in the runtime about test being an invalid module name.

test is a core library module, so the import logic finds it in the prelude and considers it to already be imported.

I see, that makes sense.

Funny, I used exactly the combination of module namespaces that doesn't work, because my 'test' module was also in a 'core' module.

I think I know what you mean, although to be clear you can't say import core at the moment with the core library, the core modules are just added to the top level of the prelude.


LHN- There is no LHN for sub task report with GBR

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.50-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N/A
**If this was caught during regression testing, add the test name, ID and link from TestRail:**N/A
Email or phone of affected tester (no customers<EMAIL_ADDRESS>Issue reported by: Applause - Internal Team
Action Performed:
Prerequisites: User A assigned sub task for user B

Navigate to https://www.staging.new.expensify.com/
Log in as user B
Navigate to the conversation with user A

Expected Result:
As their is an assigned sub task LHN should show subtask with GBR on conversation report
Actual Result:
There is no LHN for sub task report with GBR
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[x] Android: Standalone
[ ] Android: HybridApp
[x] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[x] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

https://github.com/user-attachments/assets/921a22bd-be53-466d-87b1-a522455608f3
View all open jobs on GitHub

@twisterdotcom  FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

This is expected as GBR is suppose to be shown in the chat report level instead of the task report level if the assignee can access to the chat report that the task belongs to. https://github.com/Expensify/App/pull/43927


Add purge-service-instance command

Adds a cf purge-service-instance that will recursively delete a service instance, its keys and its service bindings.
Tracker story is here.
Best wishes,
@utako, CF CAPI Team

Hi @utako,
We're no longer using github.com/cloudfoundry/cli/flags/flag. You'll need to update your PR:
diff --git a/cf/commands/service/purge_service_instance.go b/cf/commands/service/purge_service_instance.go
index d3d94b8..d04a7ef 100644
--- a/cf/commands/service/purge_service_instance.go
+++ b/cf/commands/service/purge_service_instance.go
@@ -7,8 +7,8 @@ import (
 	. "github.com/cloudfoundry/cli/cf/i18n"
 	"github.com/cloudfoundry/cli/cf/requirements"
 	"github.com/cloudfoundry/cli/cf/terminal"
-	"github.com/cloudfoundry/cli/flags"
-	"github.com/cloudfoundry/cli/flags/flag"
+	"github.com/simonleung8/flags"
+	"github.com/simonleung8/flags/flag"
 )

 type PurgeServiceInstance struct {

(You can apply that diff directly by copying it (make sure to get the newline after the last line!), then using pbpaste | git apply --ignore-whitespace. )
See b6ca76f for when we made the switch.
It'd also be super if you would rebase your branch.
Let me know if you want any help with the above.

Hey @krishicks,
I've made the changes you requested, and the branch purge_service_instance_102318490 on my fork has been rebased. Let me know if you need anything else.
Thanks,
@utako

@utako,
You'll need to update it again, but this time amending the previous commit as the previous commit isn't able to be built, and therefore isn't a green commit which passes tests.
You can do it easily with the following:
git co purge_service_instance_102318490
git reset HEAD~1
git ci -a --amend -CHEAD
git push -f git@github.com:utako/cli.git HEAD:purge_service_instance_102318490

@krishicks,
it should already be done and it looks like it's green.


Where is PyComponent in Blueprints?

Hi! Is it possible to create a PythonComponent using blueprints? I only see pyActor pyPawn and pyCharacter in the list of available blueprints.

If you mean adding it from the blueprint interface, it is called 'Python'

@rdeioris thanks for the response! Yes - I mean from the "Add New" blueprint interface. For some reason I don't see a blueprint called "Python" only the pyActor / pyPawn and pyCharacter blueprints.
Attached is an img of the search results. I must be missing something obvious here, apologies.

Found it. Its a component within an existing blueprint. Still an Unreal noob here... Closing issue.


Draft: Tests wrt opening multiple windows

This just modified the code to do some test to prepare for a version of GLMakie that supports opening multiple figures.
With this modified code, you can open multiple figures, but only the last one opened is active.
Here is some test code:
using GLMakie
fig_p = plot(sin.(1:0.1:10))
fig_p2 = plot(cos.(1:0.1:10))
fig_p3 = plot((1:0.1:10))

However, there are multiple problems:

To "activate" a second figure, for some reason not clear to me, I had to set the window handle to zero. Maybe this avoids the render loop to go over the previous figure. If the handle is not set to zero, there are some strange results, letting the figures continuously blink and not accepting display in the new figure.
If you do not set the figure handle to zero, interestingly multiple screens created via Screen() can happily coexist even without context change, and the user can move them and close them freely. Nice. However, I was unable to make these figures accept content. If I assign a plot to a screen, this sort of works but only for the first one and the plot is totally messed up.
Currently I do context switching to the new figures, and for some reason I had to call the high lever AND the low level version. This looks wrong and ugly.

Would be great, if some day Makie could do multiple figures and hopefully even non-modal and modal dialogue windows. Then it would be ready for larger real-world GUIs.

This has been picked up in: https://github.com/JuliaPlots/Makie.jl/pull/1771


Generate seed-specific client-cert/kubeconfig for gardenlet in nodeless setup

How to categorize this PR?

/area dev-productivity
/kind enhancement
What this PR does / why we need it:
When the gardenlet is locally started against the nodeless setup then a seed-specific client certificate is generated. This improves the accuracy of the SeedAuthorizer feature when it is activated.
Which issue(s) this PR fixes:
Fixes #5085
Release note:

When the gardenlet is locally started against the nodeless setup then a seed-specific client certificate is generated. This improves the accuracy of the SeedAuthorizer feature when it is activated.

/assign

Also, I noticed a new .srl file in my local git repo that is not being ignored. Can you double check?


Helm 3 is not possible to install dependent charts by executing helm install with --dependent-update on a local chart file

Output of helm version:
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2020-01-14T00:09:19Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.): kind

What happens
With helm 3.1.2, when run helm install with --dependent-update on a local chart file, it install target chart but does not install dependent charts.
If you run helm install after running helm dependency update it will install all the resources which include dependent charts. So, I think this is a bug of --dependent-update option.
How to reproduce

Create chart files locally

ex. run helm create sample
It doesn't matter chart's apiVersion (v1 or v2 either is fine)

Set at least one dependency

When using helm v2, add dependencies into requirements.yaml
When using helm v3, add dependencies into Chart.yaml

Run helm install with --dependency-update using helm v3

ex. run helm install --dependency-update sample ./sample
When run helm install, it is needed to be in a state of unresolved dependency
The point is that the requirements.lock and Chart.lock does not exist

Workaround
Update dependency before install chart.

Run helm dependency update
Run helm install

log
Using this sample chart.
This chart is created by helm create and add requirement.txt manually.
log.txt

Are you suggesting that Helm 2 and Helm 3 behave differently, or that both are doing something you did not expect?

I'm suggesting that Helm 2 and Helm 3 behave differently.
With Helm 2, running helm install --dep-up . installs all charts, including charts those depend on.
However, with Helm 3, running helm install --dependency-update test . does not install the dependent charts.
I'm expecting that Helm 3 will install all the charts, including charts those depend on, just as Helm 2 did.

Thank you for the clarification. I will look into this.

I'm working on reproducing this. I seem to be getting an error, but it is still not working as desired:
$ helm3 install --dependency-update issue7857 _scratch/issue7857
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "brigade" chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Error: directory /Users/technosophos/Code/Go/src/helm.sh/helm/_scratch/issue7857/charts/stable/chartmuseum not found

I'll continue working on this.

Okay, spoke too soon. The above error was a typo on my part.


Fix import paths in the proto files and update CI.

While you're altering this, do you want to see about fixing this warning I'm getting?
DEBUG: /usr/local/google/home/winterrowd/.cache/bazel/_bazel_winterrowd/9e65980e676170b53ccfa1ba73fad4ef/external/rules_proto_grpc/internal/compile.bzl:377:14: Inputs provided to 'deps' attr of target //third_party/arcs/proto:manifest_cc_proto_pb. Consider replacing with 'protos' attr to avoid transitive compilation. See https://rules-proto-grpc.aliddell.com/en/stable/transitivity.html

I think it involves moving the proto dependencies in cc_proto_library's (actually rules_proto_grpc's cpp_proto_library's, due to the alias in native.oss.bzl) deps list to a new protos list. But I'm not sure if that's right, it doesn't match the error message exactly. Feel free to ignore/punt if this seems like not necessary or not on-topic for this PR.

I filed #63 for now. I will take care of it in a separate PR.


Add support to wrap prover for verifying chunked step proofs

This PR fixes the remaining bugs in the wrap prover for handling chunked step proofs.
To achieve this, this PR

integrates https://github.com/o1-labs/proof-systems/pull/1279, to remove the hard-coded assumption that zk_rows = 3 in the generated expression
updates the types to marshall around the chunked public input evaluations
adds a num_chunks parameter to Pickles.compile, to allow for the creation of proofs using a different number of chunks.

With these changes, this PR now passes the local test for creating proofs using chunks in pickles. The last remaining stage is verifying those proofs recursively using the step circuit, which will be completed in an upcoming PR.

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me

!ci-build-me


Add Windows PGO builder

Add Windows64PGOBuild factory
Add Windows PGO builder to main branch
Remove a couple of dead code branches
Allow multiple workers per builder
Add ware-win11 to Windows PGO builder

Heh, so this beat me by a few minutes of my own attempt.  Still trying to figure out this review process, but based on some quick local testing, I believe I'm only seeing PGO builders for me and not you in the generated config with these changes.
Oh, and also in both our cases, a PGO builder is being created for the pull_request branch, which I don't think we need, but I haven't looked yet to see why that's not filtered out by the ONLY_MAIN_BRANCH stuff.

Ah, ok, so the issue is my quick checked filtered by workerbuilddir, and this change ends up assigning the first worker build dir to all the workers in the list.  So while the ware-win11 worker was included, it arguably had the wrong local build dir (which would be bolen-windows10).  Perhaps that's why the existing code stuck to a single worker per BuilderConfig call.  I suppose it's debatable as to why worker build dirs are based on the worker name, but that's obviously got a long history.
I'd probably just stay with the current structure and use an entry per worker for the PGO builders.  Unless you wanted to modify the change to iterate over worker_names keeping individual BuilderConfig calls per worker (and worker dir).
Oh, and clearly the pull_request branch is just handled later, and doesn't have the ONLY_MAIN_BRANCH check the main builder loop does.  Not sure why as I'd think something in ONLY_MAIN_BRANCH should be, well, only the main branch.  But adding that check to the pull_request loop as well would clearly be backwards-incompatible, though I wonder if anyone wants pull_requests to run on those non-main-branch builders?

What I'm going for here is to actually share the workload of the builder between the two workers as a proof of concept for a long-term goal of mine to simplify things to a tag-based system where we can just set things up with the right tags and the configuration will match up builders with workers for us.  That and I don't think we need two new PGO builders when two workers can share the load :)
I agree that the use of worker_name for other bits within the branch is less than ideal, and I specifically put yours first in the list to make it the "primary" here because I can deal with any fallout on my worker directly.
The builddir name matching the worker name is a historical artifact, and doesn't really mean much.  If we had used the builder name (or something based on it) in the first place, we wouldn't have had to add the 'buildersuffix' hack later on when we added extra builders to workers :).  With that in mind, what do you think of this latest commit, which will hopefully work as expected?

Oh, I definitely side with you on the goals.  I'm just not sure I'd mix those changes with the builder addition for the PGO issue, at least not in a backwards incompatible way.  I mean, the definitions change infrequently, but someone might take advantage in a future change, only to find something not working that used to (especially if converting an existing builder entry), such as a worker getting wrong or missing extra factory settings.
For build directory naming, I'd probably separate that as well, if only due to changes on existing workers involving so much disk space, so some coordination may be needed.  In particular switching names based on a builder entry being singleton vs tuple can result in unexpected disk usage on an existing worker following an update.
With that said, here's what I get for builders with the current code:
>>> pprint.pprint([(x.name,x.workernames,x.workerbuilddir,x.builddir)
                   for x in b if 'Windows PGO' in x.name])
[('AMD64 Windows PGO 3.x',
  ['bolen-windows10', 'ware-win11'],
  '3.x.bolen-windows10.pgo',
  '3.x.bolen-windows10.pgo'),
 ('AMD64 Windows PGO PR',
  ['bolen-windows10', 'ware-win11'],
  'PullRequest-nondebug-pgo-tier-1-unstable-win64',
  'PullRequest-nondebug-pgo-tier-1-unstable-win64')]

The main branch builddir is unchanged (I think you have a dangling lambda there - you're missing the "builddir=").
The PGO dir is annoyingly ugly and long, but I suppose any new naming scheme will have bike-shedding.  But perhaps introduce the naming change consistently at some point rather than just here.
I'm still wondering if main branch only builders should also be excluded from pull_request builds in general, though that would be a behavior change.  But I'm not sure any of those excluded builders would anticipate being used for pull requests too.
Perhaps consider just a nested loop in master.cfg rather than fiddling with worker_name/worker_names throughout the body?  That is, for the two loops (branches and pull requests), something like:
for name, worker_names, buildfactory, stability, tier in BUILDERS:
    for worker_name in (worker_names if isinstance(worker_names,tuple) else [worker_names]):
        ...existing body...

That way, everything should (I believe) work just as today (parallel/extra parameters, builder configuration values) regardless of builder list entry, and existing entries can be converted to use a list safely with no impact on existing workers.  Doing something different with build folder names and removing the need for extra suffix information could be a subsequent step.

The main branch builddir is unchanged (I think you have a dangling lambda there - you're missing the "builddir=").

:man_facepalming:

That way, everything should (I believe) work just as today (parallel/extra parameters, builder configuration values) regardless of builder list entry, and existing entries can be converted to use a list safely with no impact on existing workers. Doing something different with build folder names and removing the need for extra suffix information could be a subsequent step.

That can't actually work; the "extras" are actually settings for the builder rather than for the worker, even though they're stored per-worker.  We've historically not separated the two very well, with the assumption that any builder would only ever be run on one worker.
I'll just revert the attempt at a shared builder for now and go ahead with just adding the builder to your worker.

That can't actually work; the "extras" are actually settings for the builder rather than for the worker, even though they're stored per-worker. We've historically not separated the two very well, with the assumption that any builder would only ever be run on one worker.

Ah, yeah, I see, so even with an inner loop you still couldn't use the new notation anyway with workers with incompatible parallel or extra settings, which might not be obvious.  Phooey, foot gun.
Bummer.  And sorry for the negativity.  I'd be happy to help contribute to a subsequent process to try to clean some of this up though.


Implement Speech-to-Text Output in the Frontend on /doctor Route

For a streamlined workflow, it's necessary to transcribe the audio files recorded by secretaries to text. Implement a feature where the output of the speech-to-text model is displayed in the front end when accessing the /doctor route. This will allow doctors to quickly review the transcriptions and ensure accurate record-keeping. Ensure the implementation is robust and displays the transcription in a readable and organized manner, possibly with timestamps.

@Dv04 I would like to work upon this issue. Can you please assign it to me.

Sure. Glad to have you with us @parth-verma7.
Assigning now.


Arrow seperated from bubble -> arrowSide: .bottom(.mostCounterClockwise)

The arrow bottom right of the bubble is too far to the right and a gap is visible when it is displayed

Can be fixed by modifying cornerRadius of template. Closing


Skip session limitable

This updates the session_limitable strategy to allow bypassing the strategy altogether when this is desired, e.g. administrator impersonating a regular user.
After some back-and-forth I couldn't put the current implementation to use. I tried setting the warden.env and warden.request.env devise.skip_session_limitable key directly but to no avail to bring the desired results.
I've rewritten the relevant parts and retested, so one scope (administrator) impersonation another scope (user), does not have any effect on the primary user session and vice versa. If a user scope logs in (without impersonation), on a different browser, this properly interrupts the user session but not the admin's impersonating session. Unfortunately I don't think that's possible to test with rails' tests as it requires multiple concurrent, isolated one from one another requests.

Pull Request Test Coverage Report for Build 225

2 of 10 (20.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.4%) to 91.992%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/devise-security/hooks/session_limitable.rb
2
10
20.0%

Totals

Change from base Build 222:
-0.4%

Covered Lines:
896

Relevant Lines:
974

💛  - Coveralls

There's an open PR https://github.com/devise-security/devise-security/pull/74 that appears to accomplish the same thing. Does this meet your needs?

From looking at the patch it is different functionality with different goals. In #74 I think the skip flag will need to be persisted in the database, instead of persisting it in the session. This won't be useful in my case, as I want an admin to be able to impersonate users, but if the flag is persisted in the database, this flag will be applied to users too, not only to the impersonating admin's session.
#74 aims to allow certain users to have multiple sessions, my PR allows impersonation. We should figure out a way to merge those two features.

Any updates on this guys?

We agreed that I'd rebase my work on top of #74 when it gets accepted. So far it doesn't look it's going anywhere :-(

@kirichkov #74 is merged!

I just pushed some updated code, but since this can't be tested automatically using integration tests, let me do some manual tests, before merging.


Enum initialized export generates incorrect warning

Godot version
4.0 beta 6
System information
Linux
Issue description
When exporting a variable of an enum type, in this case:
@export var tween_ease: Tween.EaseType = Tween.EASE_OUT

The console generates the following warning:
W 0:00:00:0329   Integer used when an enum value is expected. If this is intended cast the integer to the enum type.
  <Error de C++> INT_ASSIGNED_TO_ENUM
  <Fuente>       custom_progress_bar.gd:6

Which doesn't really make any sense as no Integer is being cast (?)
Steps to reproduce

Create a GDScript script
Declare and initialize an enum variable as specified above
Run the code and check the warnings

Minimal reproduction project
N/A

can reproduce in 4.0 beta 9

Fixed by #69590 :)

Actually, can someone reproduce this is beta 10? I think it's been fixed by some other PR, I just happened to check it on mine!


Fix typo on kubeflow notebook quickstart guide

"exit" -> "exist" in configurations step

/assign @thesuperzapper

this must be a record, 400 days for a minor documentation fix.

@kubeflow/wg-notebooks-leads Can we please approve and merge this ?

/approve

/approve


support for img2img

Based on @chenxwh work on img2img for SD2.1, this adds img2img to generated dreambooths!
As the output image is the same size as the input image:

be sure to resize to a reasonable size (512px-1024px per side)
width and height inputs are ignored

Example using https://replicate.com/zeke/zekebooth weights
Input:

Output:

Amazing, will likely use this!

Would love to have this on the main :)

https://replicate.com/changelog/2023-01-09-dreambooth-support-for-img2img


Raise memory resource limits for vault pod

Fixes #8 - Simple case of raising expected resource requirements.

Meant to do this in fork; was an accident that I pushed to wrong remote.


ResourceLoader.load_threaded_request(...) use_sub_threads = true  not working as expected

Godot version
4.+ rc2
System information
Linux / Windows
Issue description
Using ResourceLoader.load_threaded_request(_scene_path, "", false) working as expected scene loading and everithink works (syncronized, no loading progress visible).
But if you set ResourceLoader.load_threaded_request(_scene_path, "", true) {use_sub_threads = true} scene can sometimes load, but not allways (async, loading progress visible).
Many many error messages with E 0:00:08:0869   load: Can't load dependency: res://Module Enviro Basic/MaterialsGodot/bridge.001.tres.
<C++ Error>    Method/function failed.
Steps to reproduce
Please test it with my InteractiveSceneChanger plugin.
https://github.com/VP-GAMES/Godot4InteractiveSceneChanger
InteractiveSceneChanger.gd
func start_load() -> void:
var state =  ResourceLoader.load_threaded_request(_scene_path, "", true) <= change false/true
false works perfect
true works sometimes
Minimal reproduction project
https://github.com/VP-GAMES/Godot4InteractiveSceneChanger

Could you perhaps put together an MRP so we can distinguish whether this is caused by an engine bug or misuse of the feature (perhaps because of the out-of-date documentation)?
The plugin you have linked is not a trivial example and it would take a contributor some time to debug your plugin before identifying whether this is even an engine bug.
And to clarify "res://Module Enviro Basic/MaterialsGodot/bridge.001.tres" is a resource in another project you are testing this on? I don't see the resource in the repo you linked.
An MRP should be as small as possible, but it should contain all the elements needed to reproduce the bug.

I uploaded video with bug, i try in few days create a demo project: https://www.youtube.com/watch?v=upxAnUeYFBc&ab_channel=MrVladimir

Can confirm, this completely breaks projects that use ResourceLoader with subthreads on RC2 from what I can tell.
For example, this (heavily simplified) snippet that otherwise worked before now fails to load around 3/4 of the time:
func _ready():
	ResourceLoader.load_threaded_request(GAME_PATH, "PackedScene", true)

func _process(_delta):
	var progress = []
	var status = ResourceLoader.load_threaded_get_status(SCENE_PATH, progress)
	print("Progress: ",int(progress[0]*100),"%")
	if progress[0] == 1:
		var scene = ResourceLoader.load_threaded_get(SCENE_PATH)
		var scene_instance : Node = scene.instantiate()
		get_tree().root.add_child(scene_instance)

Sometimes it will get stuck at around 79%, sometimes 59%, but almost always 60%. Sometimes it loads successfully, albeit with other strange behaviors on resources within the scene. Haven't been able to figure out a workaround yet.

I am having the same issue on MacOS 13.2.1, I hardly ever get stuck; however, the scene intermittently does not load correctly as described by others. Setting use_sub_thread to false always works. Part of my project:
class_name ThreadedLoader

extends Node

var _queue : Dictionary = {}
var _timer : Timer = null

func set_timer(timer: Timer):
	_timer = timer
	timer.timeout.connect(_on_timer_timeout)

func get_queue() -> Dictionary:
	return _queue

func request(path: String, use_sub_threads: bool = true) -> LoadSignal:
	if _queue.has(path):
		return _queue[path]
	else:
		var load_signal = LoadSignal.new()
		_queue[path] = load_signal
		if _timer != null:
			ResourceLoader.load_threaded_request(path, "", use_sub_threads)
			if _timer.is_stopped():
				_timer.start()
			return load_signal
		else:
			return null

func _on_timer_timeout():
	if _queue.is_empty() == false:
		var remove = []
		for path in _queue:
			var array = []
			var status = ResourceLoader.load_threaded_get_status(path, array)
			var progress = float(array[0] * 100.0)

			_queue[path].updated.emit(path, progress)

			if status == ResourceLoader.THREAD_LOAD_LOADED:
				var resource = ResourceLoader.load_threaded_get(path)
				_queue[path].completed.emit(path, resource)
				remove.append(path)
			elif status != ResourceLoader.THREAD_LOAD_IN_PROGRESS:
				_queue[path].completed.emit(path, null)
				remove.append(path)
		for path in remove:
			_queue.erase(path)
	else:
		_timer.stop()

class LoadSignal:
	signal completed(path: String, resource: Resource)
	signal updated(path: String, progress: float)

I should mention that I am using version 4.0.1 of Godot.

Can confirm I also experience this and in my case it seems to have something to do with diamond dependencies: main scene loading multiple different external resources, all of which have other same external resource dependency (e.g. a script). Haven't fully debugged it though.

Upgraded to 4.0.2 and now you cannot use sub threads at all, breaks every time you run. reverted to 4.0.1 and I can run sometimes with sub threads.

I've also been having the same issue. Seems to be the newer versions affecting it completely.

Upgraded to 4.0.3 rc-1 and issue appears to be fixed.

I created a simple test project using ResourceLoader.load_threaded_request(path,"", true) SampleProject and 4.0.2 would fail 100% while 4.0.3 rc2 has passed without issues.
The issue seemed to occur once an instantiated node was added to a scene to be loaded.  That said my tests would produce error E 0:00:01:0992.

That said my tests would produce error E 0:00:01:0992.

This is not an error code, but the timestamp since the project has started.

Can confirm, this completely breaks projects that use ResourceLoader with subthreads on RC2 from what I can tell.
For example, this (heavily simplified) snippet that otherwise worked before now fails to load around 3/4 of the time, regardless of the contents of the scene or if it's a new project or not.
func _ready():
	ResourceLoader.load_threaded_request(GAME_PATH, "PackedScene", true)

func _process(_delta):
	var progress = []
	var status = ResourceLoader.load_threaded_get_status(SCENE_PATH, progress)
	print("Progress: ",int(progress[0]*100),"%")
	if progress[0] == 1:
		var scene = ResourceLoader.load_threaded_get(SCENE_PATH)
		var scene_instance : Node = scene.instantiate()
		get_tree().root.add_child(scene_instance)

Sometimes it will get stuck at around 79%, sometimes 59%, but almost always 60%. Sometimes it loads successfully, albeit with other strange behaviors on resources within the scene. Haven't been able to figure out a workaround yet.

I have the same but with 50%
godot 4,2
linux

Can confirm, same here on v4.2.2.stable.official
In my case, progress doesn't go over 0 on a scene when using subthreads. I identified which approximate area of that scene causes it to stall, as when I remove the culprit nodes (which are scene instances themselves), the scene loads fine with subthreads, but didn't go much deeper into it, at the moment. No errors are produced during this, so I suppose it just silent-fails at the beginning.


Screens for Entities with navigation child properties do not link to their respective entity

Currently the various screens that display entity information only show (a text representation) of a navigation child entity. However, it is desirable to be able to link to the actual child entity.
Please define a mechanism to link to these entities and implement on all affected screens

same issue as #27 (?)


Translate “Upgrading Linux Nodes” into Korean

Translate docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes into Korean language. I did this for korean people can read this doc easily.
Issue no https://github.com/kubernetes/website/issues/40688

/close
This PR isn't making the right change.


fix: docker version compare

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA). The following contributors of this PR have not signed the OCA:

PR author: @yugasun
<EMAIL_ADDRESS>(@yugasun)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.
When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.
If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

Can not find this project in Individual OCA page


Check if async keys is array before searching for error key #818

@davidkpiano Could you please publish a new patch including this fix ? I'm having a similar bug, so I can't ship what I'm working on in production :/

@k4zuk0 Sure, I'll do it soon.


How to disable the numbers (0-9)?

Hi,
Sorry, a newbie here. Its not really an issue but rather a question. How do I disable the numbers (0-9) except the backspace when using type: VirtualKeyboardType.Numeric. Also, is it possible to remove the .? In my code, I am checking the number of characters in text. When it exceeds to 4 characters I want to disable the numbers 0-9 and only the backspace will be working. So the user can only enter 4 characters.
I will be glad if any help you can give me.

I figure out to disable the numbers 0-9.
I still could not find out how to remove the . from numeric keypad view.


modify integration scripts and .gitignore files

Modify integration scripts and local paths since whole project structure has changed.

@ilovesoup @Novemser @zhexuany PTAL

DAG
Tests run: 6841  Tests succeeded: 3766  Tests failed: 8  Tests skipped: 3067
TPCH
Tests run: 21  Tests succeeded: 21  Tests failed: 0  Tests skipped: 0


CVE-2019-5477 - Nokogiri Command Injection Vulnerability

CVE-2019-5477 - Nokogiri Command Injection Vulnerability
This issue has been created for public disclosure of a Command Injection vulnerability that was responsibly reported by @kyoshidajp (Katsuhiko YOSHIDA).
I'd like to thank HackerOne for providing a secure, responsible mechanism for reporting, and for providing their fantastic service to the Nokogiri maintainers.
Severity
Nokogiri maintainers have evaluated this as High (CVSS3 8.1)
Description
A command injection vulnerability in Nokogiri v1.10.3 and earlier allows commands to be executed in a subprocess by Ruby's Kernel.open method. Processes are vulnerable only if the undocumented method Nokogiri::CSS::Tokenizer#load_file is being passed untrusted user input.
This vulnerability appears in code generated by the Rexical gem versions v1.0.6 and earlier. Rexical is used by Nokogiri to generate lexical scanner code for parsing CSS queries. The underlying vulnerability was addressed in Rexical v1.0.7 and Nokogiri upgraded to this version of Rexical in Nokogiri v1.10.4.
Affected Versions
Nokogiri < v1.10.4
Mitigation
Upgrade to Nokogiri v1.10.4, or avoid calling the undocumented method Nokogiri::CSS::Tokenizer#load_file with untrusted user input.
Further Mitigating Actions Taken
This vulnerability could have been easily detected using Rubocop's Security cop, and so the Security cop has been introduced into the test suite. If for any reason Rubocop flags something as "insecure" in the future, that will fail the test suite and block release.
References

(private) https://hackerone.com/reports/650835
https://github.com/sparklemotion/nokogiri/issues/1915
https://ruby-doc.org/core-2.6.3/Kernel.html#method-i-open
https://github.com/tenderlove/rexical/blob/master/CHANGELOG.rdoc

History of this public disclosure

2019-07-20T19:42+00:00: empty issue-of-record created, all information is embargoed
2019-08-11T19:28+00:00: embargo ends, full information made available

Checklist:

[ ] commit to 1.10.x branch
[ ] commit to master
[ ] release 1.10.x version
[ ] update this issue with full details

v1.10.4 has been released addressing this vulnerability.

@flavorjones thanks for all your work on this and everything else you do.
I'm on the security team at GitHub these days, and noticed that this didn't come through to our advisory curation team via the NVD feed, even though you've got a CVE for it. It looks like that's because the CVE has been assigned but not published.
Would you mind prodding HackerOne to mark this as published, now that it's been publicly disclosed? We're also planning to make it easy to get CVEs through GitHub itself and have the publishing process for them automated, so hopefully we can help more here in future.

@greysteil We (HackerOne) submitted it to MITRE for publication this morning (we normally only do this once a week, unless specifically asked to do it sooner). Once they process it, should be all live.


Call to undefined method Illuminate\Database\Query\Builder::hasMeta()

Hi,
The package were tested on localhost and it's OK.
But when deployed to my website, it gives error message:
ErrorException in Builder.php line 2251:
Call to undefined method Illuminate\Database\Query\Builder::hasMeta()
I checked config/database.php and made necessary changes.
Please help.

Looks like something to do with Laravel's Auth, the one I added with 'php artisan make:auth'.
Solved problem temporarily by logging out.

Ok @ndarupurnomo thanks for the feedback. If the problem continues please tell us. Thanks!


Adding a plugin to automate some of the release management tasks

https://github.com/researchgate/gradle-release

Does this add task?

yes. It adds a release task that automates version updating and revision
control labelling.
On Mon, Nov 9, 2015 at 10:09 AM, Elliotte Rusty Harold <
<EMAIL_ADDRESS>wrote:

Does this add task?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-intellij/pull/201#issuecomment-155142992
.

lgtm


data type inference should propagate to new columns

df = data.cars() # Cylinders is inferred as nominal
df.new_Cylinders = df.Cylinders * 8 # changes type of Cylinders to quant but not new_Cylinders

In above example, when we update the types of Cylinders it should also apply to new_Cylinders since it is derived. Need to figure out when Lux sets the type for new columns, this might be easy fix

I added some codes to the __setitem__ function of the LuxDataFrame in which the data type of the new value is copied

fixed in pr


Re-implement RPC-Pay or not?

RPC-Pay is a wallet and Monero wallet RPC feature introduced in 2019 as a means to pay with hashes for the services provided by remote nodes to Monero wallet clients. An article describing it is here, the commit with technical info as commit message here.
The system needed a considerable amount of code to implement. That code is not very complex however.
It's certainly an innovative approach, and the initial enthusiasm for it was considerable. Monero mining hashes as something like a second lightweight currency within the Monero ecosystem certainly has potential, in theory, and it can gently nudge people towards using their own daemons which for the good of the network they should in many situations.
Today however monero-wallet-cli and  monero-wallet-rpc are still the only Monero wallets that implement the feature, and no plans visible to extend it to other wallets. I never heard about somebody successfully setting up a remote daemon with RPC-Pay active and people connecting to it instead of connecting to one of the many "free" as ever remote daemons that are around. I guess nowadays pretty few people even know that this exists.
In the light of all this, and with a full wallet rewrite and possibly also a full rewrite of monero-wallet-rpc on top of wallet3 instead of wallet2 with a new "unified interface", there is of course the question whether to re-implement RPC-Pay.
Personally at the moment I would propose to keep such a re-implementation in mind and try to not make it hard while implementing the new infrastructure, but not actually making it part of the first version.

RPC-Pay should be a standalone feature that the wallet doesn't need to know about. The wallet should be agnostic as to where its RPC connection comes from, whether that's directly to a local RPC, via simple free remote node, or via an RPC-Pay forwarding mechanism.

There was a discussion about the feature on the #monero-dev IRC channel, as it is part of the current Monero codebase i.e. pre-Seraphis, and nobody really voted for the feature anymore.
See log here: https://libera.monerologs.net/monero-dev/20230127#c196498


happy state?

Any thoughts on having a good job state for parsing standard output and seeing no linting errors?

PR welcome :)

I was going to discuss what that would like here then open a PR

https://github.com/eslint/eslint/issues/3495 Makes sense! Just thought snazzy was innately the visual enhancement of standard and would show a cool “good job!”


Windows

Hi, I have work a little to make the code compile and run under windows 10 with Cuda 10 and Visual Studio. Would you mind having a look to it? Best, Luis

windows support would be helpful.
should open up a new branch though.

Hi, you can have a look to my clone of this repo. On the windows branch.
Hope it helps. I only made sure it works for inference, didn't test the
training.
Best, Luis.

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/jwyang/faster-rcnn.pytorch/pull/441?email_source=notifications&email_token=ABJ4SDGAIGHTYLVMB7RQHDLQVKGCZA5CNFSM4GTJUFBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFAMUZA#issuecomment-557894244,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJ4SDCWM2LGMNUR5UXVFKLQVKGCZANCNFSM4GTJUFBA
.

Thank you very much, the model you mentioned is compilable and useful.

@LuisTbx It will make a error:

$ python setup.py build develop
running build
running build_py
running build_ext
building 'model._C' extension
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DWITH_CUDA -IG:\GP\faster-rcnn.pytorch\lib\model\csrc -ID:\ProgramData\Anaconda3\envs\pytorchFRCNN\lib\site-packages\torch\lib\include -ID:\ProgramData\Anaconda3\envs\pytorchFRCNN\lib\site-packages\torch\lib\include\TH -ID:\ProgramData\Anaconda3\envs\pytorchFRCNN\lib\site-packages\torch\lib\include\THC "-IC:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.0\include" -ID:\ProgramData\Anaconda3\envs\pytorchFRCNN\include -ID:\ProgramData\Anaconda3\envs\pytorchFRCNN\include "-IC:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\winrt" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\cppwinrt" /EHsc /TpG:\GP\faster-rcnn.pytorch\lib\model\csrc\vision.cpp /Fobuild\temp.win-amd64-3.6\Release\GP\faster-rcnn.pytorch\lib\model\csrc\vision.obj /MD -DTORCH_EXTENSION_NAME=model._C
vision.cpp
g:\gp\faster-rcnn.pytorch\lib\model\csrc\cpu/vision.h(3): fatal error C1083: ▒޷▒▒򿪰▒▒▒▒ļ▒: ▒▒torch/extension.h▒▒: No such file or directory
D:\ProgramData\Anaconda3\envs\pytorchFRCNN\lib\site-packages\torch\utils\cpp_extension.py:80: UserWarning: Error checking compiler version: [WinError 2] ϵͳ▒Ҳ▒▒▒ָ▒▒▒▒▒ļ▒▒▒
warnings.warn('Error checking compiler version: {}'.format(error))
D:\ProgramData\Anaconda3\envs\pytorchFRCNN\lib\site-packages\torch\utils\cpp_extension.py:106: UserWarning:

                           !! WARNING !!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Your compiler (cl) may be ABI-incompatible with PyTorch!
Please use a compiler that is ABI-compatible with GCC 4.9 and above.
See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html.
See https://gist.github.com/goldsborough/d466f43e8ffc948ff92de7486c5216d6
for instructions on how to install GCC 4.9 or higher.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
                          !! WARNING !!

warnings.warn(ABI_INCOMPATIBILITY_WARNING.format(compiler))
error: command 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\cl.exe' failed with exit status 2

@LuisTbx i have no idea how to solve it.
Any assistance rendered me would be highly appreciated.

Hi did you get the checkout of the windows branch?
Did you follow the installation instructions for PyCoCo?
I moved to the Pytorch official maskrcnn implementation, its way easier to
get it up and running.
Best,
On Thu., 26 Mar. 2020, 9:23 pm JXMss<EMAIL_ADDRESS>wrote:

@LuisTbx https://github.com/LuisTbx i have no idea how to solve it.
Any assistance rendered me would be highly appreciated.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jwyang/faster-rcnn.pytorch/pull/441#issuecomment-604665331,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJ4SDCYCYWZ6FCNSRRWNDDRJO2TNANCNFSM4GTJUFBA
.

@LuisTbx yeah, i get the windows branch and pycocotool
and i have gcc 6.3.0(by MinGW) and VS2017 compiler
would u mind giving me a website?

in fact, i need a pytorch Faster RCNN to write my paper, but it's hard to find a runnable project=<

That is the secret! You need to compile using VS (CL) Look for the line
about setting vcvarsall in x64 mode.
If you wanna give a try to the PyTorch official maskrcnn (frcnn) check the
tutorials in
https://pytorch.org/tutorials/intermediate/torchvision_tutorial.html
Hope it helps.
On Thu., 26 Mar. 2020, 9:41 pm JXMss<EMAIL_ADDRESS>wrote:

@LuisTbx https://github.com/LuisTbx yeah, i get the windows branch and
pycocotool
and i have gcc 6.3.0(by MinGW) and VS2017 compiler
would u mind giving me a website?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jwyang/faster-rcnn.pytorch/pull/441#issuecomment-604673932,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJ4SDCPKZUXDML4X6YBRNTRJO4XPANCNFSM4GTJUFBA
.

when i use the vs2017 x86_x64 or x64_x86 prompt, it will make another error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd3 in position 0: invalid continuation byte
(the prompt dont allow copying)
and thx for ur link=)

I used the native CMD from windows. To compile. And only used it for the
inference, so no training...
The PyTorch frcnn is very easy to use. The hardest part would be creating
the dataloader. Try having a look on how it is done in the example, it
should be straight forward to implement your own.
Best,
On Thu., 26 Mar. 2020, 9:53 pm JXMss<EMAIL_ADDRESS>wrote:

when i use the vs2017 x86_x64 or x64_x86 prompt, it will make another
error:
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd3 in position 0:
invalid continuation byte
(the prompt dont allow copying)
and thx for ur link=)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/jwyang/faster-rcnn.pytorch/pull/441#issuecomment-604680070,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABJ4SDA3N35AVV4IXIWASM3RJO6GLANCNFSM4GTJUFBA
.

but i cant compile the cuda dependencies, how miserable! T_T

It does work，thank you！


Example showing how to use iai_macro

I played a bit with iai yesterday and was really impressed by the stable results. Then I also made a quick attempt to use the iai_macro but couldn't figure out what to do. Could you add a simple example?

Hey, thanks for trying Iai. Good suggestion.
In the meantime, it's basically the same deal as for Criterion.rs, only use #[iai] for your benchmark functions instead of #[criterion].

Hey, thanks for trying Iai. Good suggestion.
In the meantime, it's basically the same deal as for Criterion.rs, only use #[iai] for your benchmark functions instead of #[criterion].

Got it! I had disabled the testing harness. I enabled it again and things started working just fine.

Note that for #[criterion] benchmarks, we don't need to disable the normal testing harness as we do with regular Criterion.rs benchmarks.

I read this as "it doesn't matter if you disable the normal testing harness or not". But I guess the harness is really needed.
I think just copy-pasting this: https://github.com/bheisler/iai/blob/main/macro/benches/test_macro_bench.rs
to the readme, together with the relevant bits of Cargo.toml and two lines of explanation would be enough.

Got it! I had disabled the testing harness. I enabled it again and things started working just fine.

Note that for #[criterion] benchmarks, we don't need to disable the normal testing harness as we do with regular Criterion.rs benchmarks.

I read this as "it doesn't matter if you disable the normal testing harness or not". But I guess the harness is really needed.
I think just copy-pasting this: https://github.com/bheisler/iai/blob/main/macro/benches/test_macro_bench.rs
to the readme, together with the relevant bits of Cargo.toml and two lines of explanation would be enough.

Please see https://github.com/bheisler/iai/pull/6

Please see https://github.com/bheisler/iai/pull/6


Move backend docs from rst docstings to MyST markdown files

The backend module docstrings are relatively detailed now, and I'd rather not have to keep writing rst if possible.
I think it just needs a few tweaks to add some more sources, copy them to the apidoc dir, and use those instead of the auto-generated ones.

Codecov Report

Merging #585 (7beceae) into master (166f569) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #585   +/-   ##
=======================================
  Coverage   98.71%   98.71%
=======================================
  Files          20       20
  Lines        1561     1561
  Branches      247      247
=======================================
  Hits         1541     1541
  Misses         10       10
  Partials       10       10

Impacted Files
Coverage Δ

requests_cache/backends/sqlite.py
99.02% <ø> (ø)

requests_cache/session.py
98.38% <ø> (ø)

Continue to review full report at Codecov.

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


Fill out actions & reducer for unlock-folders

@keybase/react-hackers
Fills out most of the actions for the unlock folders screen.
I'm not sure what service request hitting continue here is suppose to do? I can add that in a future PR.

Todo before I'll merge this:

[ ] Figure out on the meaning of life DeviceType.

Maybe @patrickxb can shed some light here? Device.type in the avdl is just a string
And it looks like for the most part it's value are only 'desktop' | 'mobile' | 'backup'. Defined here which has a note that it should match with what's in keybase/keybase
But it looks like we change the names 'desktop' -> 'computer' and 'backup' -> 'paper key' in this function
and that is called from engine/login_provision
which seems weird to me. I feel like the engine should be consistent with what types it uses, and the ui (cli / gui) should be mapping these to friendly names.
From I understand so far whenever we interact with engine we should use 'desktop' | 'mobile' | 'backup'. Except when the engine asks the ui to choose a device for login3 provisioning. In that case we are given devices with types 'computer' | 'mobile' | 'paper key'

:+1: lets talk to patrick about the types. might be related to being backwards compatible


Could not find image name

$ fluxctl release --all --update-image=quay.io/weaveworks/billing-usage:0.3.0
Submitting release job...
Release job submitted, ID 3b85d97f-3545-5b09-1156-3d0569d826c9
Status: Update 1 images(s) in the resource definition file for billing/billing-usage: billing-usage (quay.io/weaveworks/billing-usage:0.2.0 -> quay.io/weavewoStatus: Failed: updating pod controller for quay.io/weaveworks/billing-usage:0.3.0: Could not find image name

Here's as far as we got:
 1) Submitted job.
 2) Calculating release actions.
 3) Release quay.io/weaveworks/billing-usage:0.3.0 to all services
 4) service default/kubernetes does not have images associated: empty selector
 5) service kube-system/scope-probe does not have images associated: no matching replication controllers or deployments
 6) Clone the config repo.
 7) Clone OK.
 8) Update 1 images(s) in the resource definition file for billing/billing-usage: billing-usage (quay.io/weaveworks/billing-usage:0.2.0 -> quay.io/weaveworks/billing-usage:0.3.0).
 9) updating pod controller for quay.io/weaveworks/billing-usage:0.3.0: Could not find image name
 10) Failed: updating pod controller for quay.io/weaveworks/billing-usage:0.3.0: Could not find image name
Took 29.028194s

It might be because the image tag is all numbers and dots.

See PR #241

Fixed by #241.


Roll to Dart SDK 1.20.0-dev.5.0.

bumps to 1.20.0-dev.5.0.
updates analyzer API use.

This one needs a few fixes before it can land but wanted to get it up for folks to look at.
[error] Could not infer type parameter T, RenderObject must be of type T. (packages/flutter_test/lib/src/controller.dart, line 222, col 30)
[error] Could not infer type parameter T, Widget must be of type T. (packages/flutter_test/lib/src/controller.dart, line 77, col 30)

/cc @Hixie , @leafpetersen, @jmesserly for input.

In this code (the other one is analogous):
 Iterable<Widget/*=T*/> widgetList/*<T extends Widget>*/(Finder finder) {
    TestAsyncUtils.guardSync();
    return finder.evaluate().map((Element element) => element.widget);
  }

I believe that element.widget is of type Widget (I haven't tracked this down entirely, so correct me if I'm wrong).  The strong mode contract that is written there promises to return an Iterable<T>, where T is some arbitrary subtype of Widget.  Inference is failing here, since it can't find a choice which satisfies the contract.   You can explicitly fill in the type for it:
    return finder.evaluate().map/*<T>*/((Element element) => element.widget);

or put an explicit check:
    return finder.evaluate().map((Element element) => element.widget as dynamic /*=T*/);

or put an implicit check, but since Dart doesn't (yet) have a way to write return types on lambdas, you need to name the function to do that:
    /*=T*/ reader(Element element) => element.widget
    return finder.evaluate().map(reader);

Thanks @leafpetersen!

I believe that element.widget is of type Widget (I haven't tracked this down entirely, so correct me if I'm wrong).

Nope.  That's right!
I'm leaning towards your first suggestion of explicit typing and will update the PR.
Cheers!

Build is clean now.  @Hixie PTAL at the code contortions and let me know what you think...

Thanks @abarth!
@Hixie : feel free to nudge me if you want to follow up with any tweaks to the type error solutions I picked. 👍

LGTM. In general I'd like the code to not rely on inference at all. The idea is to use inference to verify that the code is correct.


Add someone to GitHub

Please include:

GitHub ID to add: @genaris
Project to be added to: Aries Framework JavaScript

One of:

Team to be added to:  https://github.com/orgs/hyperledger/teams/aries-framework-javascript-committers

We would like to add @genaris as a maintainer to the Aries Framework JavaScript project. He has been active participant in the community and contributor to the framework for a considerable amount of time.

Invite sent! Please update your maintainers.md file as well.


x64 driver hash different from security catalog in 3.8 release zip

I've attempted to install the 3.8 driver on a Windows 10 Pro 19042 x64 machine.
Using the provided batch script, the installation fails with "devcon-x64 failed." as the error message. This left an "Unknown device" entry in Device Manager.
When I attempted to directly specify the Inf file for that device through Device Manager's 'Update driver' option, I got the following error message:
"The hash for the file is not present in the specified catalog file. The file is likely corrupt or the victim of tampering."
At first I thought perhaps this was a rather confusing error message stemming from the driver signing issue mentioned in the README. However, I've previously installed Scream drivers on this machine and I was able to verify that the drivers from version 3.7 do install properly.
So, I think perhaps the catalog file for at least the x64 driver in the packaged zip file for release 3.8, is outdated compared with the driver Inf and kernel module files that are included in the same zip file.

Hmm it works for me. However I only have one system to test right now. Anyone else have that problem with the 3.8 ZIP package?

Should probably provide a few more details about what I'm seeing from the catalog file.
In all of the catalog files I've checked (Scream drivers version 3.7 and 3.8 x64, plus some of the VirtIO drivers for windows that I happened to have handy) the hashes for the .sys files don't match what I get from certutil or other tools, so I assume that is due to me not understanding what portion of the .sys file is actually used for calculating the hash which gets stored in the catalog file.
However, only for the Scream 3.8 drivers (the x64 ones at least), the hash for the .inf file also does not match. This is not the case for any of the other drivers I've checked which do install properly.
So in the latest release zip file we have:

scream-3.8\Install\driver\x64\Scream.inf - SHA256 is 628970688AF81E8CE714D2C8A7366959322BE84C2376AC1D384B3488DCBD3B56
scream-3.8\Install\driver\x64\Scream.cat - SHA256 is 132525AE9E8751F2556E21C31EFCFBC01BA1CB0B6A1EF0DB17501005D278B32E
Inside of the above catalog file, the SHA256 thumbprint for scream.inf is 5262C6BE24D2439550150037B3F027ABAE617E010A0F542552E20FC78BFF3F9A


Provide a command to reinstall an extension

A developer command to reinstall an extension from Market place.

This should delete the extension from the disk and install it freshly from the market place
This command is supported only for user installed and market place extensions

@egamma FYI


Create iaeste.sk

You need to use the txt file extension

@tomasfarkasovsky Could you please rename lib/domains/sk/iaeste.sk to lib/domains/sk/iaeste.txt? Thank you.

Dear Philip,
I will do it today as soon as possible.
Thank you for patience.
Tomas
2017-05-02 1:07 GMT+02:00 Philip Torchinsky<EMAIL_ADDRESS>
@tomasfarkasovsky https://github.com/tomasfarkasovsky Could you please
rename lib/domains/sk/iaeste.sk to lib/domains/sk/iaeste.txt? Thank you.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/JetBrains/swot/pull/2995#issuecomment-298456203, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AP-txy_Euvx16nZeejG4L1nl4v-o6KSIks5r1mWdgaJpZM4NMh9A
.

@tomasfarkasovsky Pull request merged. Thank you!


[BUG] TypeError: Cannot read properties of undefined (reading 'replace')

Version
1.10.3 build 91
What platform are you using?
Android
OS Version
14
What happened?
After trying to configure the sync to my webdav (koofr cloud) account every time I try to sync or just open the app I get msg TypeError: Cannot read properties of undefined (reading 'replace') , I have setup to auto sync in open .
When I configure my webdav sync I check status before  press save button and result is Successful  !
Any help , I missing something ?
Thanks.
Relevant log output
No response
Code of Conduct

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

Sounds similar to the error on Android, when exporting a document to pdf.

I had the same issue when trying to sync to a Nextcloud WebDav using password authentification. I seemed to have solved it by using an "App password" instead of the user account password. I don't know if there's a similar feature in your cloud, but here's the steps for Nextcloud: Settings > Security > Create new app password (bottom of the page) > In OSS Document Scanner, select Password and copy the app password generated by Nextcloud.

I had the same issue when trying to sync to a Nextcloud WebDav using password authentification. I seemed to have solved it by using an "App password" instead of the user account password. I don't know if there's a similar feature in your cloud, but here's the steps for Nextcloud: Settings > Security > Create new app password (bottom of the page) > In OSS Document Scanner, select Password and copy the app password generated by Nextcloud.

I use a separate password for webdav , but I find the issue. I missing to add remote folder to sync I leave this empty in the setup menu . Is strange because when I test is show Successful w/o adding remote folder name to this field .
Thanks .

Should be fixed now

which version fixes the issue ?

@stavpup https://github.com/Akylas/OSS-DocumentScanner/releases/tag/com.akylas.documentscanner%2Fandroid%2Fgithub%2F1.11.1%2F96 should fix it


booster-bdd: Update email addresses in job notifications.

[test]

Can one of the admins verify this patch?


GSD Request

--- GSD JSON ---
{
  "vendor_name": "Linux",
  "product_name": "Kernel",
  "product_version": "versions from  to before v5.4.181",
  "vulnerability_type": "unspecified",
  "affected_component": "unspecified",
  "attack_vector": "unspecified",
  "impact": "unspecified",
  "credit": "",
  "references": [
    "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cfc8b37ef0418529e3719c2d128e59e74a3114b0"
  ],
  "extended_references": [
    {
      "type": "commit",
      "value": "cfc8b37ef0418529e3719c2d128e59e74a3114b0",
      "note": "fixed"
    }
  ],
  "reporter": "joshbressers",
  "reporter_id": 1692786,
  "notes": "",
  "description": "ax25: improve the incomplete fix to avoid UAF and NPD bugs\n\nThis is an automated ID intended to aid in discovery of potential security vulnerabilities. The actual impact and attack plausibility have not yet been proven.\nThis ID is fixed in Linux Kernel version v5.4.181 by commit cfc8b37ef0418529e3719c2d128e59e74a3114b0. For more details please see the references link."
}
--- GSD JSON ---

This issue has been assigned GSD-2022-1000350


fix: gateway upgrade

Need to fix windows build issues, but think this might be a good spot to roll up the PR and do the rest in a follow up. Which is 80% around the unixfs stuff.


Validate worker exception handling and logging

I ran into an issue while testing -- we were throwing a NullRef in here: https://github.com/Azure/azure-functions-dotnet-worker/blob/main/src/DotNetWorker/Definition/DefaultFunctionDefinitionFactory.cs#L20, but I wasn't seeing any log in the host. We need to ensure that exceptions in code like this make it back to the host for logging/debugging.

Fixed with #245


 SPIRE has published scratch images that contain only the SPIRE release binary since v1.1.0 to GHCR as ghcr.io/spiffe/<image>.
Update references to alpine images in GCR to scratch images in GHCR. Update places where a version < 1.1.0 is used to reference the latest version of SPIRE, as the scratch images are only published to GHCR as of v1.1.0.

Thank you @rturner3 This is great! We'll take it from here! 👍

Thanks @mrsabath! I noticed in the failing CI job that the Dockerfiles are trying to install curl in the spire-server container. From what I see there are a few options, depending on the requirements:

Remove the step of the Dockerfiles that installs curl
Use a builder image like alpine in the Dockerfile, install curl in the builder image, then copy the curl binary into the Tornjak images
Build from a different base image like alpine and copy the SPIRE binaries into the Tornjak image

If the fix is straightforward, I'm happy to contribute it in this PR since it doesn't look like this is safe to merge as is.

Thank you @rturner3 for reaching out. We fixed it by separating the Tornjak images from Spire (see https://github.com/spiffe/tornjak/pull/100) This is the most elegant way. We can still keep them both in a single pod, but as separate containers (e.g. a sidecar). This new Tornjak image is based on alpine, to address the lacking shell in scratch.

Hi @mrsabath @lumjjb are there any other changes you need me to make in order to get this to a state where it can be merged? We are hoping to stop publishing the SPIRE alpine-based images starting in 1.6.0.

We are retiring the deployment model when Tornjak is together with SPIRE in the same container, in lieu of separate containers that can be deployed in the same pod. Tornjak requires alpine base in order to run shell commands. This change requires  a new documentation that is still referencing the old images. See issue #111


Type generator exists in middleware but is missing in Schema.

Hi,
since the graphql-middleware update to 6.1.2 I get the following error:
MiddlewareError: Type generator exists in middleware but is missing in Schema.
I do use graphql-shield v 7.5.0

Update: I think the error wars next.js experimental: { esmExternals: true },
At least for now it seems to work. For the latest version as well.

I'm running into the same error with anything above 6.0.10 Not using next.js, using webpack / babel (latest versions of both)

Update: I think the error wars next.js experimental: { esmExternals: true },
At least for now it seems to work. For the latest version as well.

I just tested a Next.js project using esmExternals: true and graphql-middleware and everything works fine, and I executed all the tests on ESM and nothing fails

I'm running into the same error with anything above 6.0.10 Not using next.js, using webpack / babel (latest versions of both)

We need a reproduction repo / instructions to be able to debug it, I really tried to find this issue by myself, I just tested a lot of things and nothing fails

Yeah sorry. I didn't dig deeper as I have things that I need to finish. If it shows up again I'll have a look as well.
Thanks for your work! 🤗

I'm encountering this same problem.
I'm new to this biome, so not sure what is important info to relay, but I'm using graphql-middleware 6.1.6, graphql-shield 7.5.0, apollo-server-express 2.25.2, and neo4j-graphql-js 2.19.4.

Relevant code bits (maybe). Note that makeAugmentedSchema comes from https://github.com/neo4j-graphql/neo4j-graphql-js (not sure if that's important):
const typeDefs = fs
  .readFileSync(
    //process.env.GRAPHQL_SCHEMA || path.join(__dirname, 'schema.graphql')
    process.env.GRAPHQL_SCHEMA || './schema.graphql'
  )
  .toString('utf-8');

const schema = makeAugmentedSchema({
      typeDefs: typeDefs
});

const isAuthenticated = rule({ cache: 'contextual' })(async (parent, args, ctx, info) => {
  return ctx.user !== null
});

const isAdmin = rule({ cache: 'contextual' })(async (parent, args, ctx, info) => {
  return ctx.user.roles.includes('admin');
});

const permissions = shield({
    Query: {
        "*": allow,
    },
    Mutation: {
        "*":  and(isAuthenticated, isAdmin)
  },
})

const server = new ApolloServer({
  context:
    async ({ req }) => {
        console.log("setting up context");

		//get user from token
        const token = req.headers.authorization || '';
        const user = await getUser(driver, token);

        // Add the user to the context
        return {
            user,
            driver,
            driverConfig: { database: process.env.NEO4J_DATABASE || 'neo4j' },
        };
    },
  schema: applyMiddleware(schema, permissions),
  introspection: true,
  playground: true,
})

I've been trying different versions of graphql-middleware and am seeing the same as @todda00: the problem starts with 6.1.0.

as already mentioned, @NoisyFlowers can you create a minimal reproduction repo? I already tried a lot of stuff trying to reproduce it and I couldn't

I have this issue and the fix presented above.
OS: macOS 11.4
Node: 14.18.1
npm: 6.14.15
graphql-middleware: "^6.1.12"
graphql-shield: "^7.5.0"
changing the middleware loader to graphql-middleware: "6.0.9" fixed things

Facing same problem . Solved by downgrading middleware version 6.0.6.

Facing same problem . Solved by downgrading middleware version 6.0.6.
Are there any fix yet?

facing this problem tried downgrading, recently upgraded to nextjs 12

still same problem,
6.0.9 solves the problem

Reverting to version 6.0.9 and pinned it. Fixed my problem. Would love to see this fixed so I can update the latest version.

To downgrade graphql-middleware package to 6.0.9, do command
With npm: npm uninstall graphql-middleware and npm install<EMAIL_ADDRESS>With yarn: yarn remove graphql-middleware and yarn add<EMAIL_ADDRESS>

I downgraded to 6.0.10, but because my project directly depends on @graphql-tools/schema  I also had to downgrade that lib to ^7.1.5 to match the dependency version in<EMAIL_ADDRESS>Hope this helps.

it seems downgrading is the only way to fix this issue right now. Can this be fixed on graphql-middleware side or is it because of interactions with libraries?

isMiddlewareGenerator is incorrectly returning false for graphql-shield permissions, which causes this error to occur in the validation.
If you replace applyMiddleware(schema, permissions) with applyMiddleware(schema, permissions.generate(schema)) then it will work correctly with the latest version of graphql-middleware, without needing to downgrade.

isMiddlewareGenerator is incorrectly returning false for graphql-shield permissions, which causes this error to occur in the validation.
If you replace applyMiddleware(schema, permissions) with applyMiddleware(schema, permissions.generate(schema)) then it will work correctly with the latest version of graphql-middleware, without needing to downgrade.

This worked for me!
Thanks!

Any updates on this issue?