cmd/compile: diagnose unused variable even in closure

package main

func main() {
    i := 0
    go func() {
        i = 1
    }()
}

This compiles without errors.
I would expect this to give an "i declared and not used" error.

Without having fully dug into this I am hypothesizing this might just be a consequence of us taking the address of higher scope variables to make a pointer then technically "assigned" to it
so it perhaps became the equivalent of
var i int
*(&i) = 1

thus when used in the closure got rewritten as
var i int
go func(i *int) {
    *i = 1
}()

which if true would then mean that a fix for this would involve specially marking as used scoped-by-manually-address-of'd variables that were previously just values in their original scope
so in pseudo code
in closure or inner scope, for &prefixedVariables from an outer scope {
    on assignment, markAsUsed iff:
        Originally a pointer in outer scope
}

Kindly paging @griesemer @randall77 @mdempsky for discussion and perhaps to help me check my hypothesis and then I can mail out a fix if plausible.

Yes, we're effectively doing &i when building the closure, which defeats the unused variable analysis.
I'm not sure what the fix would be. We'd need to keep track of, for every variable whose address is taken, whether that address was used in a read or a write (or unknown).  It sounds tricky.

It needs to be done independently of (the implementation detail) whether an address was taken. go/types does this right, but it also does it earlier, during type-checking.
Not urgent.

It's not urgent, but it is an ongoing pain point, because different compilers behave differently.  That causes people to write code that works with one compiler and complain when it fails with a different one.  So it really ought to be fixed.

vet detects this but compiler is happy. internal_response is never used.
func (s *AnaServer) VisualizationEvent(ctx context.Context, in *pb.VisualizationEventReq) (*pb.VisualizationEventRes, error) {
...
	internal_response := &ana.VisualizationEventRes{}

...
	if err := customcopier.CopyRecommendedDashPageReq(request.DashPage, in.GetDashPage()); err != nil {
		return nil, err
	}

	if err := s.AnaRpc(func(client ana.GateClient) error {
		internal_response, err = client.VisualizationEvent(ctx, request)
		return err
	}); err != nil {
		return nil, err
	}

	return &pb.VisualizationEventRes{}, nil
}

I have CLs uploaded to fix this for Go 1.16 (CL 238537, CL 238317).
@ianlancetaylor points out this might break programs that currently build, and so maybe we should only apply impose the new, stricter behavior when -lang=go1.16 is used (e.g., go 1.16 in a go.mod file). I've prepared CL 238538 to implement this conditional behavior.
gccgo, go/types, and cmd/vet all diagnose the original test case as an error. I'm hopeful that we can avoid introducing conditional behavior in cmd/compile. But if we need to make it conditional, I think that's reasonable.
Relatedly, if all major Go compilers/type-checkers now require all declared variables to be used, we should consider changing the "implementation restriction" into a plain restriction (like how directly imported packages have to be used).

Any comments on whether the stricter behavior should be decided by -lang=go1.16 or just enabled by default (i.e., consistent with gccgo, go/types, and cmd/vet)?

If my program pulls in third party packages as many programs do, and those third party packages don't use vet, then it's possible that my program will suddenly stop building if we make this change, and that the only way for me to fix the build will be to edit third party packages.  That seems undesirable.  Therefore, unfortunately, I think we do have to condition this on a language flag.
In effect I think we are removing a language feature as described at https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md#language-removals, the language feature in this case being something like "the ability to only set a variable and never use it as long as one of the sets is in a closure."  Since we are removing a feature, we should use a language flag.
Sorry.
Just my opinion, of course, happy to hear other opinions.

If my program pulls in third party packages as many programs do, and those third party packages don't use vet,

I believe it's even more restrictive than that in practice. go test automatically runs go vet, go vet must be able to process all recursive dependencies. (It appears to have essentially its own parallel build process, with intermediate analysis artifacts instead of compiled code.) So the risk of breakage here is limited to packages that don't use go vet / go test and don't have any users that use them either.
Test setup w/ package example.com/a that uses this anti-feature, and example.com/b that depends on it:
$ cat a/go.mod
module example.com/a
go 1.16

$ cat a/a.go
package a
func f() {
	x := 0
	func() {
		x = 1
	}()
}

$ cat b/go.mod
module example.com/b
go 1.16
replace example.com/a => ../a
require example.com/a v0.0.0-00010101000000-000000000000

$ cat b/b.go
package b
import _ "example.com/a"

$ cat b/b_test.go
package b_test
import "testing"
func TestFoo(t *testing.T) {}

Here go vet and go test report failures (exit code 2) for package example.com/b because go/types rejects example.com/a:
$ ( cd b; go vet; echo $? )
# example.com/a
vet: ../a/a.go:4:2: x declared but not used
2

$ ( cd b; go test; echo $? )
# example.com/a
vet: ../a/a.go:4:2: x declared but not used
PASS
ok  	example.com/b	0.008s
2

In effect I think we are removing a language feature as described at https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md#language-removals, the language feature in this case being something like "the ability to only set a variable and never use it as long as one of the sets is in a closure." Since we are removing a feature, we should use a language flag.

Pedantically, the general language feature ("ability to only set a variable and never use it") is already optional, and not supported by most implementations (including cmd/compile, most of the time). I think that distinguishes it from integer-to-string conversions like discussed in that section, as those conversions are a mandatory feature.
I would argue the example from https://go.googlesource.com/proposal/+/refs/heads/master/design/28221-go2-transitions.md#language-redefinitions is more applicable: "For example, in Go 1.1 the size of the type int on 64-bit hosts changed from 32 bits to 64 bits. This change was relatively harmless, as the language does not specify the exact size of int. Potentially, though, some Go 1.0 programs continued to compile with Go 1.1 but stopped working."
Similar to not specifying the size of int, the language does not specify whether the feature "the ability to only set a variable and never use it as long as one of the sets is in a closure" is available. I'm sure it would have been frustrating to have a third-party dependency that assumed int was 32 bits and stopped working in Go 1.1, but the proposal seems to conclude this was relatively harmless, nonetheless.

Thanks for looking into it.  I'll let someone else adjudicate.

I think I'd rather use the go1.16 flag. There's no point in breaking people's programs unnecessarily. Unlike, say, the reflect.SliceHeader issue, not using a variable isn't going to create silent bad behavior.

We're running into this on dev.typeparams, because the race detector has some test code that only compiles with cmd/compile because of this bug. (The tests are obviously trivially fixable with just three lines.)
I'm still of the opinion that 0 real-world programs depend on this today, because of the go test behavior I pointed out above; and that if any code does depend on it, that it's not guaranteed by the Go 1 compat guarantee anyway, which says "Unspecified behavior. The Go specification tries to be explicit about most properties of the language, but there are some aspects that are undefined. Programs that depend on such unspecified behavior may break in future releases."
We routinely fix compiler bugs without guaranteeing backwards compatibility. For example, this program builds with Go 1.16 and prints "1", due to a compiler bug that fails to detect overflow from the unary ^ operator: https://play.golang.org/p/elofakyGeMh. I've fixed this bug on dev.regabi and the program is now rejected with a "constant bitwise complement overflow" error.
If we need a language flag to control taking away the "ability to only set a variable and never use it as long as one of the sets is in a closure" feature, do we need one to control taking away the "ability to construct 512-bit integers by using bitwise complement to bypass overflow detection" feature too?
If #23116 hadn't been fixed until after the introduction of -lang, would it too have required backwards compatibility for the "ability to declare guarded type switches without any cases" feature?
What about #28085? If gccgo starts rejecting case 3 to match cmd/compile and go/types, would it continue supporting the "ability to use duplicate constant values in interface-typed switch statements" feature when compiled with -lang=go1.16?
Or order of evaluation? This program prints 0 with cmd/compile. If I were to modify SSA construction so it instead prints 1 like gccgo, will we continue supporting the "slice expressions are handled like function calls for order-of-evaluation purposes" feature for backwards compatibility?
Where does it end?
I don't think we should be bound to maintain particular, unspecified behavior. I think we specify expected and allowable language behavior for a reason.

We're running into this on dev.typeparams, because the race detector has some test code that only compiles with cmd/compile because of this bug. (The tests are obviously trivially fixable with just three lines.)
I'm still of the opinion that 0 real-world programs depend on this today, because of the go test behavior I pointed out above; and that if any code does depend on it, that it's not guaranteed by the Go 1 compat guarantee anyway, which says "Unspecified behavior. The Go specification tries to be explicit about most properties of the language, but there are some aspects that are undefined. Programs that depend on such unspecified behavior may break in future releases."
We routinely fix compiler bugs without guaranteeing backwards compatibility. For example, this program builds with Go 1.16 and prints "1", due to a compiler bug that fails to detect overflow from the unary ^ operator: https://play.golang.org/p/elofakyGeMh. I've fixed this bug on dev.regabi and the program is now rejected with a "constant bitwise complement overflow" error.
If we need a language flag to control taking away the "ability to only set a variable and never use it as long as one of the sets is in a closure" feature, do we need one to control taking away the "ability to construct 512-bit integers by using bitwise complement to bypass overflow detection" feature too?
If #23116 hadn't been fixed until after the introduction of -lang, would it too have required backwards compatibility for the "ability to declare guarded type switches without any cases" feature?
What about #28085? If gccgo starts rejecting case 3 to match cmd/compile and go/types, would it continue supporting the "ability to use duplicate constant values in interface-typed switch statements" feature when compiled with -lang=go1.16?
Or order of evaluation? This program prints 0 with cmd/compile. If I were to modify SSA construction so it instead prints 1 like gccgo, will we continue supporting the "slice expressions are handled like function calls for order-of-evaluation purposes" feature for backwards compatibility?
Where does it end?
I don't think we should be bound to maintain particular, unspecified behavior. I think we specify expected and allowable language behavior for a reason.

The program below relies on cmd/compile's historical "ability to assume pointers to zero-size objects allocated in and returned by functions that contain for loops will always compare equal" feature, which has been supported since at least Go 1.1. However, with Go 1.16 beta 1, even with -gcflags=all=-lang=go1.15, it now silently compiles to a program that panics instead:
package main

func main() {
	if f() != f() {
		panic("FAIL")
	}
}

func f() *[0]byte {
	for {
		return new([0]byte)
	}
}

Should we file a release-blocker issue because Go 1.16 will break programs that depend on this behavior?
I argue no. The Go spec says "Pointers to distinct zero-size variables may or may not be equal." and consistent with that, we've allowed whether any particular such comparison compares equal or not to change over time. And notably, this change is silent, arbitrary, and largely unpredictable. It's also a recurring source of user issue reports (e.g., #43755 was filed just 4 days ago; see https://github.com/golang/go/issues?q=is%3Aissue+"zero-size+variables" for past instances). There's not even a vet warning that these comparisons are unspecified.
Meanwhile, the Go spec also says "A compiler may make it illegal to declare a variable inside a function body if the variable is never used." And to contrast with the above, presumably acceptable change in pointer-comparison behavior, the change in question for this issue would align cmd/compile's behavior with gccgo and go/types existing, long-term behavior (i.e., wholly predictable and understandable), and programs that are impacted (whose existence I still doubt) will fail loudly rather than silently.

The program below relies on cmd/compile's historical "ability to assume pointers to zero-size objects allocated in and returned by functions that contain for loops will always compare equal" feature, which has been supported since at least Go 1.1. However, with Go 1.16 beta 1, even with -gcflags=all=-lang=go1.15, it now silently compiles to a program that panics instead:
package main

func main() {
	if f() != f() {
		panic("FAIL")
	}
}

func f() *[0]byte {
	for {
		return new([0]byte)
	}
}

Should we file a release-blocker issue because Go 1.16 will break programs that depend on this behavior?
I argue no. The Go spec says "Pointers to distinct zero-size variables may or may not be equal." and consistent with that, we've allowed whether any particular such comparison compares equal or not to change over time. And notably, this change is silent, arbitrary, and largely unpredictable. It's also a recurring source of user issue reports (e.g., #43755 was filed just 4 days ago; see https://github.com/golang/go/issues?q=is%3Aissue+"zero-size+variables" for past instances). There's not even a vet warning that these comparisons are unspecified.
Meanwhile, the Go spec also says "A compiler may make it illegal to declare a variable inside a function body if the variable is never used." And to contrast with the above, presumably acceptable change in pointer-comparison behavior, the change in question for this issue would align cmd/compile's behavior with gccgo and go/types existing, long-term behavior (i.e., wholly predictable and understandable), and programs that are impacted (whose existence I still doubt) will fail loudly rather than silently.

Since switching to the types2 type checker in Go 1.18, the compiler unconditionally rejects the sample code with "i declared but not used". I think this issue is fixed.


[zh] unify spec section translation for all workloads

Description
[zh] unify spec section translation for all workloads
Issue
Closes: #

Please confirm all the in-synced content have been updated in these 3 files. Refer to: https://kubernetes.io/zh-cn/docs/contribute/localization_zh/#update

Confirmed.


Update to git 2.7.4.

CVE-2016-2315
CVE-2016-2324

r? @brson
(rust_highfive has picked a reviewer for you, use r? to override)

Thanks!

Damn, thanks for staying on those CVEs.


Maths not displayed in variational inference writeup

This page does not render math:
https://turinglang.org/dev/docs/for-developers/variational_inference

nice!


Keep GitHub Actions up to date with GitHub's Dependabot

Automate the creation of pull requests like

#2552

Fixes software supply chain safety warnings like at the bottom right of
https://github.com/apache/solr/actions/runs/9893380263

Keeping your actions up to date with Dependabot
Configuration options for the dependabot.yml file - package-ecosystem

https://issues.apache.org/jira/browse/SOLR-XXXXX

Description
Please provide a short description of the changes you're making with this pull request.
Solution
Please provide a short description of the approach taken to implement your solution.
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[ ] I have created a Jira issue and added the issue ID to my pull request title.
[ ] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[ ] I have developed this patch against the main branch.
[ ] I have run ./gradlew check.
[ ] I have added tests for my changes.
[ ] I have added documentation for the Reference Guide

Could the same be achieved using our existing Renovate bot, instead of introducing a different bot? https://docs.renovatebot.com/modules/manager/github-actions/

I read through that but could not see how those instructions aligned with .github/renovate.json.

I have made an attempt to enable the github-actions manager for renovate in #2559. Let's see if it works..

Thanks for bringin up this issue @cclauss, even if your pr was not used. I now got the renovate bot working, after tweaking an access token with workflow permission. See #2562 for an example PR created.


Firefox Webextension

Hi! I'm a really big fan of your extension, and use it daily. Lately though I've been transitioning to Firefox and was wondering if you'd be open to port this.
Since Firefox 57 I believe, Firefox enforces a new Addon-Technology called "WebExtensions" which basically build upon chrome extensions. So it should be relatively easy to do.
A few helpful links I've found:

A Step-by-Step Guide of how RES was ported from Chrome to a FF WebExt
Official FF Docs on How to Port
Let Mozilla check if your Chrome extension is base-compatible with WebExt
Packaging an extension folder into a .CRX file (needed for extensiontest.com)
Temporarly install the extension in Nightly

What I did so far:

cloned this repo
packaged the extension into a .csr
run the csr agains extensiontest.com, which yielded: https://www.extensiontest.com/test/28052fb0-92f9-11e7-97dd-c97ef306ba23

{
  "compat": [],
  "errors": [
    {
      "message": "Banned 3rd-party JS library",
      "locations": [
        {
          "file": "js/jquery-1.11.2.min.js"
        }
      ]
    }
  ],
  "warnings": [
    {
      "message": "Inline scripts blocked by default",
      "locations": [
        {
          "file": "popup.html"
        }
      ]
    },
    {
      "message": "Unsafe assignment to innerHTML",
      "locations": [
        {
          "file": "popup.js",
          "line": 463
        }
      ]
    }
  ]
}

tried the extension in Nightly, and it mostly worked (he keybindings wouldn't work and the numbers icon wouldn't reload)

I'd appreciate it, if someone other would take a look at this, and if I have some more time in the future, maybe I'd even spend some more time on it.

I would love to be able to use this in Firefox as a replacement for my beloved "All Tabs Helper."  I switch between browsers frequently and the consistency would be much appreciated.  Now that FF57 is in beta, I'm even more desperate to find solid replacements like this.  It should also work in Vivaldi, Opera, etc.

If somebody could mentor me in making a Firefox extension, I'm more than happy to try to put this over the line.

Not really hard: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Porting_a_Google_Chrome_extension

A working alternative is Most-Recent-Tab, which uses the shortcut Control-shift-1 on Windows and Command-shift-1 on Mac.
Since the shortcut can't be customized at this very moment, I created a fork to change the shortcut to Ctrl+Shift+E, which is a bit closer to the shortcut this very extension was using.

@engelju The alternative you've provided seems to have a very limited set of features compared to this extension -- it seems the only functionality it offers is navigating to the last-used tab?

@ErichDonGubler yup, sorry I should have clarified that. The linked web-extension only provides a shortcut for the most recent tab.

While searching for an alternative to use with firefox, i stumbled across tab-search.
It should cover most of the basic needs quick-tabs provides.

saka is also pretty nice, and having it on ctrl+space is quite handy.

If anyone is searching for a good solution for Firefox, the original All Tabs Helper has now been ported to a WebExtension.  Perhaps soon it will even come to Chrome!

@hackel @3v1n0  @omares thanks! I'll check it out.
However, I still hope Quick Tabs will get ported to FX.

As an alternative, I use Vim Vixen's buffer feature to search and nav to specific tab: (press b then type)

It works. But not good. Hope to see Quick Tabs ported to FireFox one day.

TabSearch is great too.

While there could be alternatives I'd prefer to have this one to be ported as wide as possible. Say, Opera and Firefox.
Moreover, since Quick Tabs is a great time saver to me (thank you) and anyways I was thinking to donate just out of gratitude I'd gladly pay a contribution for this work to be done. And if others interested users would join it could be some money and hopefully enough money to have it done. ;-)

Just voicing my support for a Firefox port. The UI and behavior of this extension (on Chrome) is preferred to me over some of the alternatives I've looked at.

Here's an un-official port of Quick Tabs for Firefox. Hoping for the official one soon! It's literally the one extension keeping me on Chrome.
https://addons.mozilla.org/en-US/firefox/addon/quick-tabs-ported/

@vancetran: That port works wonderfully. Thank you for linking it!

Here's an un-official port of Quick Tabs for Firefox. Hoping for the official one soon! It's literally the one extension keeping me on Chrome.
https://addons.mozilla.org/en-US/firefox/addon/quick-tabs-ported/

I've been using this FF ext few months, as I'm moving away from Chrome back to FF. Its stable.
I'd volunteer someone with free time 😜 to collaborate with the dev, who from the FF plugin ratings comments seems open enough, to fork this repo and paste/merge the current FF addon code into the fork. The fork can then be easily maintained and kept up-to-date etc.

Alright, I'll be that guy and bump this. This is a fantastic extension, and it's a shame that Firefox users don't have a first-class experience like what this extension provides yet. The ported clone seems to work fine, so I don't see a reason that this can't be done straightforwardly. What I want to know is this: are maintainers open to merging changes for Firefox compatibility? I'd be more than happy to take initiative if that's the case -- but I don't want to waste time, having never needed to maintain an FF extension before.
@babyman, if you're not interested in tackling this issue, that's fine. This is an open-source world, and your time and energy are finite. It'd sure be nice if you'd let us know, though!

It's all good, thanks for being that guy :).  I really just want to clean up the stale tickets to leave things open that are still relevant and of interest to everyone.  I'm going to flag this as a feature request to keep it open and prevent the bot picking it up again.

Is there a fork for the firefox code?
Although I'd really prefer to have this merged in this repo...
In case is not, would be nice to support also keybindings to move around the view (like to choose the selected item).

There's no fork for FireFox, ideally it would work using the standard APIs but I'll take a look and see what's involved.
I haven't used FF in ages but I hear it's making a strong comeback.

@3v1n0 @babyman: One can inspect the source code of the [ported clone for Firefox]](https://github.com/babyman/quick-tabs-chrome-extension/issues/189#issuecomment-497402949) by version here, but there's no Git database in the archives (I ran unzip -l quick_tabs_ported-1.0.6-fx.xpi from a *nix terminal), which means some work would have to be done to figure out what revision the porting changes were applied to. Annoying, though not am impossible task.

After doing some digging, the last commit in this repo's history that could be the base version of the ported extension is 0c13cdf1a0d6f5f96adbfe0c84f8c88e2f09d461, which I've marked in my fork under the maybe-port-fork-point branch. Most of the diffs aren't outrageous, but I wonder if there's a better match for those the base commit of those changes.

Please port it for use in firefox. There's no decent alternative to this extension on the entire addons.mozilla.org. There's TabSearch but it still falls short on the feature list, functionality and, honestly, doesn't look good either.

@vancetran @ErichDonGubler @kyle0r @3v1n0 @a-pav
Are you all still using the unofficial port that vancetran linked?
I was using it fine for years and then randomly it stopped giving keyboard focus to the search box upon activation via keyboard shortcut. This makes it pretty clunky to use now. I did test it on a few fresh Firefox installs and different computers, but I'm wondering if any of you are having the same issue.

@DesertBanana:

I was using it fine for years and then randomly it stopped giving keyboard focus to the search box upon activation via keyboard shortcut. This makes it pretty clunky to use now. I did test it on a few fresh Firefox installs and different computers, but I'm wondering if any of you are having the same issue.

I run into the same issue, and it has caused me to abandon what was otherwise a solid flow.  🫤 I have recently adopted a tab tree extension (Sidebery too!), and that's served a lot of the use case I originally had for fuzzy searching, but it's not a perfect replacement.

@DesertBanana

@vancetran @ErichDonGubler @kyle0r @3v1n0 @a-pav
Are you all still using the unofficial port that vancetran linked?
I was using it fine for years and then randomly it stopped giving keyboard focus to the search box upon activation via keyboard shortcut. This makes it pretty clunky to use now. I did test it on a few fresh Firefox installs and different computers, but I'm wondering if any of you are having the same issue.

I'm still using the Firefox "quick-tabs-ported" extension. A bug has developed with a recent Firefox release - like you mentioned with the search field focus issue. For me the reproduction of the bug was intermittent, most of the time it does not focus on the search field when the popup opens, sometimes it does. I've noted that mouse clicking on the toolbar button does seem to focus on the search field whereby keyboard shortcut activation invariably does not focus on the search field.
If you look at the comments on the extension page, others users have also posted snippets of fixes/tweaks for other topics. This motivated me to see if I could fix the focus issue, which I think I have been able to do.
One can inspect the extension code via the Firefox developer tools. Info on how to debug popup.html on superuser here. Once you're debugging popup.html you can check out popup.js on the debugger tab.
Unfortunately it looks like ad-hoc edditing/patching via script override via the Firefox Developer tools does not work at this time. See this related Mozilla Ideas post here.
Here is a screenshot from FireFox v131:

Here are the steps I followed:

I downloaded the latest xpi and extracted to a folder (xpi's are in zip format)
Made changes to the extension code
Used the "Load Temporary Add-on..." feature
It is located on the about:debugging#/runtime/this-firefox page.
Select the mainifest.json from the extracted folder.

Using this approach I was able to load and test changes to the extension. There might be better / more efficient way to develop extensions in real-time but this worked for this quick edit.
Note that each change to the source required me to "Load Temporary Add-on..." again.
One could make such changes permanent repackaging and installing the patched xpi. One would need to temporarily tell Firefox to ignore add-on signatures via about:config xpinstall.signatures.required.
In 2024-Oct I had a short email chat with the original Firefox extension author about tips on how to make changes to the extension, and the above 👆 is my knowledge share. I'm assuming the author doesn't have time/interest to maintain the extension at this time.
It would still be nice to have an official Quick Tabs Firefox extension or at least a maintained fork but until then, I hope this info helps.
The changes I made to fix the focus issue are visible on this Gist.  The changeset is ~2 lines of real code.
https://gist.github.com/kyle0r/2dd8d30a6d1f335b68feb468293a8466/revisions#diff-3df6958c77d615b266b54fcf12fadf313e7c1e4b168f0c61ea8c3424eb39eb8c
Here is the main gist link: https://gist.github.com/kyle0r/2dd8d30a6d1f335b68feb468293a8466

@kyle0r Thanks for your hard work! As I am non-technical person, I would greatly appreciate a repackaged and hosted xpi. Please let me know if you end up doing this.

@kyle0r Thanks for your hard work! As I am non-technical person, I would greatly appreciate a repackaged and hosted xpi. Please let me know if you end up doing this.

No worries.
It did a bit of research on re/packaging extensions. It looks like my information about disabling extension signing only applies to non "release" versions of Firefox. So the developer and nightly builds and perhaps the ESR builds. So for "release" versions... signed extensions are required otherwise Firefox refuses to install the xpi.
Research suggests it should be relatively straightforward to repackage and sign and existing extension on the "unlisted" channel. Assuming it's easy to obtain a set of Mozilla developer credentials, I will give it a go in the coming days and if I have any success I'll share the details and hopefully a signed "unlisted" xpi.

@kyle0r Thank you!!

OK, I made and verified an AMO account (addons.mozilla.org). I was able to set up an API Key and follow the instructions on stackoverflow here to create and sign the attached modified XPI under a new unlisted extension id.
This is an unlisted modification of Quick Tabs Ported version 1.0.6
@DesertBanana @ErichDonGubler You should find a zip file link (attachment to this post). Inside the ZIP is the new xpi.
I've have designated this version: <IP_ADDRESS>.
Download link: quick_tabs_ported-<IP_ADDRESS>.zip (attached/hosted here on this issue thread)
ZIP archive checksums:
SHA256:<PHONE_NUMBER>195a572399410d2bc47688c35515bb7260b8c020c213caf04b5976
SHA1: c56aedc7c5f3945eca3eb7468c43ae844723135d
Quick Tabs Ported <IP_ADDRESS> Changelog

Fixed issue with search field focus when the popup is triggered.

As suggested by a reviewer: pwrsurge [link]:
Added option/feature MinSearchQueryLength which defaults to 1 which maintains the default/historic behaviour.

As suggested by reviewer: reid [link]:
Added <body> margin styling to resolve cosmetic issue with the [x] close button being pushed off the right of the popup and the overflow being hidden/covered by the vertical scrollbar.

Installation
💡 The attached extension is signed by Mozilla but is unlisted and has a different id/identifier to the original Quick Tabs Ported extension. This identifier mechanism prevents arbitrary changes/takeovers of an existing extension. A side effect is that the extension will be treated as a separate/different extension to the existing listed extension. Therefore the old/existing extension must be disabled or removed to avoid issues/conflicts/confusion.

Extract the xpi from the zip, note the path
[IF ENABLED] Open the about:addons page and disable to previous/old Quick Tabs Ported Add-on
Open the about:addons page and choose Install Add-on From File... from the gear menu

You will need to check / set the extension options (don't forget to click the apply button)
You will need to check Manage Extension Shortcuts from the about:addons gear menu to set your preferences

Is this safe?

Yes, it should be. The <IP_ADDRESS> xpi has been scanned, signed and approved by Mozilla via their web-ext.js sign tool.
The required extension permissions are unchanged
Normal Firefox releases will not install unsigned or corrupt extensions
Here is the virustotal result for the zip.
You can use your local virus scanner to check the archive.
You can use a tool like Beyond Compare [link] to make a diff of the xpi archives. See screenshot.

The signed and official Quick Tabs Ported 1.0.6 version xpi link is here.

30 second video of the changeset
https://github.com/user-attachments/assets/337725e4-f407-47ae-aafe-2776c4f3f86e
A few notes from development

Delete the META-INF folder from the original extracted XPI
Make and test the changes to the extension
(about:debugging#/runtime/this-firefox → Load Temporary Add-on... → Browse to the extracted manifest.json)
Use the reload button on the Temporary Add-on to pick up changes
One-time change: in manifest.json

change the gecko -> id key to a new GUID [link]

For each release to be signed: increment the version key in mainifest.json
Note: versions cannot be reused/republished.
Follow the instructions: https://stackoverflow.com/a/59172713/490487
Use web-ext.js lint as many times as needed to check the extension for issues prior to web-ext.js sign

@kyle0r: WFM now! Woot! 😀

@kyle0r I tested it and it works perfectly, thank you so much!


Error when running evaluation script - ModuleNotFoundError: No module named 'swebench'

When I try to run the run_evaluation.sh script (or the python run_evaluation.py --all --the --args --... script for that matter) from the swebench/harness directory, I get the following error:
Traceback (most recent call last):
  File "/swebench_workspace/SWE-bench/swebench/harness/run_evaluation.py", line 15, in <module>
    from swebench.harness.constants import (
ModuleNotFoundError: No module named 'swebench'

Adding the SWE-Bench directory to my PYTHONPATH like below before running the script solves the issue
PYTHONPATH=/swebench_workspace/SWE-bench:$PYTHONPATH  ./run_evaluation.sh

Hi @brombaut thanks for pointing this out, some of this functionality likely changed since we restructured the repository to be reflective of how the swebench pypi is built.
Thank you for putting down the tip. It is also possible to run evaluation using the swebench pypi package, which doesn't require building from source. You can find an example here.

Hi!
Just cloned the repo with a fresh conda install as well, same thing happened to me. Should this issue really be closed?

Yeah I pulled the updated changes, fresh environment setup, still got this error. I will say that doing pip install swebench did fix the issue, but I want to make local changes, so that doesn't really work for me (and also the same i mentioned in the original issue report still works, so that's the workaround)

I'm also getting this error and I cloned and set up this repo today. The error happened when I ran ./collect/run_get_tasks_pipeline.sh  as part of the Collections tutorial


favicon and Page width

Thx @puresyntax71 , I really like your themes, it's very beautiful. But I have two issues:

How to modify the page width of the post？ I think the default setting is a bit narrow, I do not know in which file to modify.
How to add favicon for web pages?

Put the favicon in static/favicon.ico and it will be copied to public when it serves.

How to add favicon for web pages?

Yeah, as @chris-gillatt mentioned. I'll also try to add in the path later on.

How to modify the page width of the post？ I think the default setting is a bit narrow, I do not know in which file to modify.

Might need to override the style here from bootstrap (see the "Customization" section). I guess you can give this a try - https://getbootstrap.com/docs/4.0/layout/grid/#variables.

Put the favicon in static/favicon.ico and it will be copied to public when it serves.

thanks~It worked.

How to add favicon for web pages?

Yeah, as @chris-gillatt mentioned. I'll also try to add in the path later on.

How to modify the page width of the post？ I think the default setting is a bit narrow, I do not know in which file to modify.

Might need to override the style here from bootstrap (see the "Customization" section). I guess you can give this a try - https://getbootstrap.com/docs/4.0/layout/grid/#variables.

@puresyntax71 In \themes\hugo-theme-chunky-poster\layouts\post\single.html, location code snippet

                            {{ $page.Content }}

                        {{- with $page.Params.tags -}}

                            {{- range . -}}

                                    {{ . }}

                            {{- end -}}

                        {{- end -}}

                        {{ partial "sharer.html" . }}

The default width of page is
，I change col-lg-8 to col-lg-12, the options are col-lg-8, col-lg-10, col-lg-12. col-lg-12 is great.

Ah, totally forgot that one. Good one!


maint: build wheels for macos arm64 in Cirrus CI

This adds Cirrus CI configuration that can build macOS arm64 wheels.
Cirrus CI needs to be enabled on the repo before this will work.

@fredrik-johansson can you enable Cirrus CI on this repo?
The link is here:
https://github.com/marketplace/cirrus-ci
Only the "public repositories" (free) level is needed. After it asks for a name and address and some access to your github account to see your repos. It's possible to enable it only on one repo though.

Cirrus CI seems to be installed now.

Thanks. Looks like it's working. It should take about 15 minutes to produce the wheels.

It's working. I've tested one of the wheels locally.
Next what is needed is to patch gap:
https://github.com/aleaxit/gmpy/issues/352#issuecomment-1360941902
I want to try to reproduce this issue first so that I can confirm the fix:
https://github.com/aleaxit/gmpy/issues/350

I want to try to reproduce this issue

Actually I'm really not sure how I would reproduce that because obviously I've compiled python_flint rather than gmpy. The equivalent code for python_flint doesn't have any problem but that doesn't really prove anything. I think it's clear that GMP needs to be patched though (various other environments apply this patch for macos arm64).

I've added the patch for OSX arm64 and tested the wheel from Cirrus CI locally and it works.

Okay, I think this is good to go.


Test optional scope parameter in token refresh sequence

Addresses #246 which was a request for improved testing on our token refresh.  We also made a number of changes, including:

Condensed what used to be three tests into a single test, because we needed to duplicate that single test to handle multiple cases.  It was far too repetitive to keep the same test structure.
Identified a number of minor issues in the SMART spec that went unnoticed earlier.  We had to change some of our tests to accommodate that (noted in the referenced issue).
Significantly bulked up our self testing

You can try out these changes by executing out the refresh token sequence on any server

I believe I've addressed all the comments.  All excellent points.


Constants (e.g. class, module, etc) defined inside an example_group leak.

Say I have a spec:
#!/usr/bin/env rspec

RSpec.describe "define some module" do
	module MyModule
	end
end

RSpec.describe "a different example group" do
	it "should not have module defined" do
		expect(defined?(MyModule)).to be == nil
	end
end

I get the following output
a different example group
  should not have module defined (FAILED - 1)

Failures:

  1) a different example group should not have module defined
     Failure/Error: expect(defined?(MyModule)).to be == nil

       expected: == nil
            got:    "constant"
     # ./test.rb:10:in `block (2 levels) in <top (required)>'

Finished in 0.01106 seconds (files took 0.09443 seconds to load)
1 example, 1 failure

Failed examples:

rspec ./test.rb:9 # a different example group should not have module defined

I don't know if this is expected, but it seems odd that constants defined in one example group would leak into another.

While not ideal, it's known, expected behavior.  In Ruby, when you define a constant in a block, it uses the module scoping of whatever is outside the block as the constant namespace.  For example:
irb(main):001:0> Foo = Class.new do
irb(main):002:1* BAR = 5
irb(main):003:1> end
=> Foo
irb(main):004:0> BAR
=> 5

In this IRB session, BAR was defined at the top level scope, (e.g. ::BAR or Object::BAR), not as Foo::BAR like you might expect.  This is simply how Ruby works and there's nothing RSpec can do about this.  (And since it's how ruby works, I'm not sure that we should try to do anything different.)
In your example, module MyModule in the describe block has defined a top-level MyModule constant that is accessible from anywhere in the program.  That's why you're seeing this behavior.

Okay, if that's the case, one option is to document this somewhere and explain the following:
RSpec.describe "define some module" do
	module self::MyModule
	end
end

RSpec.describe "a different example group" do
	it "should not have module defined" do
		expect(defined?(MyModule)).to be == nil
	end
end

Prepending self:: does work as expected.
I believe there are some other options too, hold on while I check this.

Yep, Ruby allows you to explicitly namespace a constant with self:: so that works.  Here's the same thing in IRB:
irb(main):001:0> Foo = Class.new do
irb(main):002:1* self::BAR = 5
irb(main):003:1> end
=> Foo
irb(main):004:0> BAR
NameError: uninitialized constant BAR
        from (irb):4
        from /Users/myron/.rubies/ruby-2.3.0/bin/irb:11:in `<main>'
irb(main):005:0> Foo::BAR
=> 5

Regarding documenting this -- we could, but bear in mind that this has nothing to do with RSpec.  Any document would just be documenting how Ruby works with regard to constant definitions and blocks.

I think it's a common enough tripping point, I've seen it in several projects and wondered if there was a better solution. In the end, people tend to try and shove stuff in a shared scope but it's a bit of a pain.
e.g. https://github.com/celluloid/timers/blob/fcb443006ed1770d3ba2ebf3db0e0d2e570c6672/spec/spec_helper.rb#L7-L8 used to actually be defined as Q = ... within the RSpec.describe block but it turned out it was just redefining the constant over and over again.
My work around in the past was to define specs inside their own module, but that also seems a bit disingenuous and makes the syntax of tests a bit cumbersome.

Hmm, so I found some additional problems, using the self:: prefix causes other classes to break, because they can't find each other. I guess I'll revert back to my original approach of wrapping the whole spec in a module.

By the way, thanks for your detailed explanation.

You might also try stub_const as it provides a way to define a constant for a single example and have RSpec revert it when the example completes.

Ah yep. In this particular example, I have several top level classes which I'd need to deal with.
https://github.com/ioquatix/mapping/blob/8fe2d7128df320f7375eadc3da83ad1b88e02979/spec/mapping/model_spec.rb

Or, if you need a module defined in just one spec, make it dynamically, and then clean up?
RSpec.describe 'my test', type: :awesome do
  some_module = Module.new do
    # some code
  end
  receiver = self
  receiver.const_set(:SomeModule, some_module)
  after(:all) do
    receiver.send(:remove_const, :SomeModule)
  end
end

This is one thing that is way more explicit in minitest land, since I can just use an ensure in the test aka method.
Rails does this sort of thing all the time and just handles it manually.
But, I guess the RSpec procsy object could check for const_added and then have them removed /shrug

@bf4 That's an interesting option.
I guess it would be nice if there was a simpler option.
Perhaps something like
#!/usr/bin/env ruby

module RSpec
	class Test
		def self.it(*args, &block)
			puts args
			yield
		end
	end

	def self.describe(*args)
		klass = Class.new(Test)

		klass.const_set('ARGS', args)

		return klass
	end
end

class MyTest < RSpec.describe 'my test'
	class Foo
	end

	it 'should be okay' do
		puts "Foo is defined: #{Foo.inspect}"
	end
end

@bf4 that's no different to doing:
RSpec.describe 'my test', type: :awesome do
  module self::SomeModule
    # some code
  end
end

The module isn't then available outside the 'my test' module anyway so no need to clean it up. The downside to both these approaches is having to reference modules by self.class:: inside the tests as their blocks are also scoped to the outside by Ruby.
If you're just looking for scarificial modules which to test things like inclusion etc, you're better off creating them attached to local variables or let's, and letting the garabage collector clean them up.

@JonRowe what are scarificial modules?

A typo for sacrificial, e.g. a module you want for a test then throw away.


changes behaviour regarding scihub URLs

To get around the fact that sci-hub URLs are always changing, the URL now needs to be passed as an argument to the SciHub class constructor.

I assume you made this change because whereisscihub.now.sh is down? I replaced that URL with https://sci-hub.now.sh/ in the code, and it seems to be working as intended once again.

Hard coding the Sci-Hub URLs is just a bad idea. 'https:/sci-hub.now.sh/' may go down as 'https:/whereisscihub.now.sh/' did. Passing the base URL as an argument is far better in this case where URL is likely to change

That's a good point, although we can't assume that every such site can be parsed with the same code. The best solution would be a simple, standardized, cURL-able resource that would provide a list of viable SciHub URLs, so we could skip all the beautifulsoup nonsense.


Use progress element for XP bar

Before:

After:

Does this break in firefox? I checked MDN and it seems those pseudo elements are unsupported.

Forgot to add its selector, but here it is with it:


Paper draft build

Docs and paper draft have been compiled into build-docs branch. Need to merge these into main, particularly because each time we commit to main, to documentation builds upon the docs files contained in main, which are now out of date.

Hi @alextbradley, nice work! Just had a quick review as I'm in transit, but one think that might be really nice is to remove all the .DS_Store files within the repository. They're artifacts from someones MacOS installation. They can be added to the .gitignore once removed from the tree (there are a few from what I can tell), but otherwise this looks lush! 👍🏼

Looks good to me! I only looked closely at the WAIS example that I provided the data for. The only thing I found wrong was this bit...
"We have a 268 x 315 with, with 3km resolution."
Needs changing for 5km example.
I also noticed these missing references  in the Melt Rates part..
\eqref{E:plumeparametrization}, rather than \eqref{E:picoparametrization}.
Otherwise, great job!


hcsshim hash mismatch on main

Description
https://github.com/containerd/nerdctl/commit/ea7769fcf20ad2209239ca62d1b80140205aa242 broke the build on main:
2024-03-25T22:34:26.8827740Z verifying<EMAIL_ADDRESS>checksum mismatch
2024-03-25T22:34:26.8828716Z 	downloaded: h1:qbmS+ZplURcyTJi8IseYDay+FdDdtHqtjxg5e4/PlPw=
2024-03-25T22:34:26.8829367Z 	go.sum:     h1:ahSMCguNOQMvTV7wWLknLhpieyqA2hUyEb3j6R+6B/c=
2024-03-25T22:34:26.8829752Z
2024-03-25T22:34:26.8829862Z SECURITY ERROR
2024-03-25T22:34:26.8830294Z This download does NOT match an earlier download recorded in go.sum.
2024-03-25T22:34:26.8830971Z The bits may have been replaced on the origin server, or an attacker may
2024-03-25T22:34:26.8831518Z have intercepted the download attempt.
<EMAIL_ADDRESS>may have changed on the origin before Dependabot downloaded it.
Steps to reproduce the issue

Clone main branch
go mod tidy to delete package cache
Attempt to build nerdctl

Describe the results you received and expected
Received:
2024-03-25T22:34:26.8827740Z verifying<EMAIL_ADDRESS>checksum mismatch
2024-03-25T22:34:26.8828716Z 	downloaded: h1:qbmS+ZplURcyTJi8IseYDay+FdDdtHqtjxg5e4/PlPw=
2024-03-25T22:34:26.8829367Z 	go.sum:     h1:ahSMCguNOQMvTV7wWLknLhpieyqA2hUyEb3j6R+6B/c=
2024-03-25T22:34:26.8829752Z
2024-03-25T22:34:26.8829862Z SECURITY ERROR
2024-03-25T22:34:26.8830294Z This download does NOT match an earlier download recorded in go.sum.
2024-03-25T22:34:26.8830971Z The bits may have been replaced on the origin server, or an attacker may
2024-03-25T22:34:26.8831518Z have intercepted the download attempt.
Expected: perfect build.
What version of nerdctl are you using?
master
Are you using a variant of nerdctl? (e.g., Rancher Desktop)
None
Host information

Fixed with hcsshim v0.12.2: https://github.com/microsoft/hcsshim/releases/tag/v0.12.2


samples: task_wdt: generic watchdog channel

Some targets like stm32wb55 and their boards have watchdog mapped
on node 0 or 1 when using this sample.
Using a generic reference for the sample.yaml makes test complete successfully.
Signed-off-by: Francois Ramu<EMAIL_ADDRESS>

wrong channel control


Interaction

Keys and Doors working. Going to need parsing for exit square done hopefully by @ForbiddenKJ as he has been working on all that.
[] Add new issue to do exit tile
[] Add new issue to add sound effect
closing #39

i'm not merging anything with an emoji in it

At work now, if the code is in a state to merge. Feel free to remove the emojis and SEND IT

could you merge this branch, interaction, with the branch interactable-objects


Seems to be broken on Hyprland while launching on startup

Hi!
I use NixOS with Hyprland-git. If I launch waycorner in my terminal, it works as intended, but if I put it in autolaunch, it won't register cursor, while waycorner --preview in autolaunch still draws its zone
Perhaps this is due to the transition to aquamarine recently and the fact that the cursor spawns in the upper left corner

I'm not sure how to help you without debug information. Could you please run it in the environment where it's not working using RUST_LOG="debug" waycorner and provide the output? I also don't know what you are referring to with autolaunch or aquamarine, perhaps because I'm not a NixOS user.

By autolaunch I mean
exec-once=swaync
exec-once=waybar
exec-once=kitty
exec-once=waycorner

I think sway also have similar way to make programs launch on startup.
Aquamarine is new wayland implementation for hyprland.
This is RUST_LOG="debug" waycorner launched in terminal, when everything works:
  RUST_LOG="debug" waycorner
2024-08-18T14:12:04.164929Z DEBUG waycorner::config: Replacing ~/ with $HOME/
2024-08-18T14:12:04.164958Z  INFO waycorner::config: Using config: /home/artem/.config/waycorner/config.toml
2024-08-18T14:12:04.169037Z  INFO waycorner::wayland: OutputInfo { id: 47, model: "0x1D8F", make: "AU Optronics", name: "eDP-1", description: "AU Optronics 0x1D8F  (eDP-1)", location: (0, 0), physical_size: (290, 180), subpixel: Unknown, transform: Normal, scale_factor: 1, modes: [Mode { dimensions: (1920, 1200), refresh_rate: 60026, is_current: true, is_preferred: true }], obsolete: false }
2024-08-18T14:12:04.169078Z DEBUG waycorner::wayland: Corner { config: CornerConfig { output: None, enter_command: ["rofi-appgrid"], exit_command: [], locations: [TopLeft], size: 10, margin: 20, timeout_ms: 250, color:<PHONE_NUMBER> }, channel: (Mutex { data: Sender { .. }, poisoned: false, .. }, Mutex { data: Receiver { .. }, poisoned: false, .. }) }
2024-08-18T14:12:04.169103Z DEBUG waycorner::wayland: Output description IS a match
2024-08-18T14:12:04.169107Z DEBUG waycorner::wayland: Adding surfaces
2024-08-18T14:12:04.169116Z  INFO waycorner::wayland: Adding anchorpoint Top | Left
2024-08-18T14:12:09.626755Z DEBUG waycorner::corner: Received event: Enter
2024-08-18T14:12:09.876951Z  INFO waycorner::corner: executing command: rofi-appgrid []
2024-08-18T14:12:11.372934Z  INFO waycorner::corner: output received: Output { status: ExitStatus(unix_wait_status(0)), stdout: "", stderr: "" }
2024-08-18T14:12:11.372974Z DEBUG waycorner::corner: Received event: Leave
2024-08-18T14:12:11.372991Z DEBUG waycorner::corner: Ignored the event due to too fast after unlock.
^C

Is there a way to get output of the command in a file? I think it is the only way for me to get it launching without terminal.

I'm pretty sure "autolaunch" is able to redirect the output to a file. You might be able to wrap it in a bash or similar invocation. You'll need to see how to do that for yourself however. I am possibly able to assist once you're able to get me a debug log where it fails.


Resend endpoint issue (resend email change issue)

Bug report
The endpoint /resend is not working properly. When you have a user that was registered by phone, and it's confirmed. Then if you add an email to the user and try to resend the verification email using /resend endpoint, the confirmation email is not sent.
Describe the bug

Register a user with a phone
Verify the phone
Add email to that user, using the method updateUser (the confirmation email is sent)
Call the endpoint /resend to resend the confirmation email (the mail is not sent)

Issue:
To invoke 4, we are calling the resend endpoint with two parameters:
{
          'email': email,
          'type': 'email_change',
        },

Then, if I take a look at your code:
	if params.Email != "" {
		user, err = models.FindUserByEmailAndAudience(db, params.Email, aud)
	} else if params.Phone != "" {
		user, err = models.FindUserByPhoneAndAudience(db, params.Phone, aud)
	}

	if err != nil {
		if models.IsNotFoundError(err) {
			return sendJSON(w, http.StatusOK, map[string]string{})
		}
		return internalServerError("Unable to process request").WithInternalError(err)
	}

The server finds the user by the email address. However in the DB table, the email address is null, and the email is in email_change column. The reason is that the email is not associated with the user because it's not verified.
To fix this issue, in the case that the user has not had a confirmed email, the resend method should accept the phone number as the identifier (the confirmed method).

Hi @mirland, thanks for catching this! We just put up a PR for this already so it should be fixed soon.

Hi @kangmingtay thanks for the fix. However, I'm testing exactly the same case and it's not working.
I'm invoking the same endpoint with the same data, the server returns 200 but the email is not sent.
Can you help me?
BTW: I checked and the email is in email_change column.
Also I testing sending the resend with type email_change and also with signup but it's not working


Tuya cl Curtain Switch (unsupported) da Tuya error and no command up/down/stop

The problem
No work

Device Information
Product Name Smart Curtain
Device ID
Product Category cl
Device Status Online
Activated At 2020-05-06 18:20:15
Data Center Central Europe Data Center
Extension Information
Sub-Device or Not
What version of Home Assistant Core has the issue?
2021.11.5

I have the same issue. Is there a solution?

I have the same Issue
Some more info: - These are Quoya smart curtains (via Amazon) - they did previously work in older HA.
Product Name: 窗帘电动轨道
Product Category: cl
Json:
[
{
"code": "mach_operate",
"value": "STOP"
},
{
"code": "opposite",
"value": true
},
{
"code": "position",
"value": 0
}
]
Standard Instruction Set:
mach_operate | Enum | {   "range": [     "ZZ",     "FZ",     "STOP"   ] }
opposite | Boolean | "{true,false}"
position | Integer | {   "unit": "%",   "min": 0,   "max": 100,   "scale": 0,   "step": 1 }
Standard Status Set:
opposite | Boolean | "{true,false}"
mach_operate | Enum | {   "range": [     "ZZ",     "FZ",     "STOP"   ] }
position | Integer | {   "unit": "%",   "min": 0,   "max": 100,   "scale": 0,   "step": 1 }

#652 Same Issue

Yesterday, Home Assistant 2022.2 was released.
Could you try upgrading to that version and see if the issue has been resolved?
If not, Home Assistant 2022.2 contains a new diagnostic tool. There is now a "Download Diagnostics" button on each Tuya device on the device page. Clicking that button will download diagnostics information for that specific device. Drag the downloaded file into this issue. It will help with finding out what the problem is.

Yes the issue has been resolved!


Reduce file size by embedding binary data instead of using base64

Update template.sh to modify the shell script and use build.sh to rebuild the sticker.webp executable when necessary.

мяяяяяяяу :pleading_face:


T76677 Gltf Imports are splitted into chunks

https://developer.blender.org/T76677

It's expected that meshes get split into chunks with continuous UVs/normals/tangents/colors of course. The obvious question is why the exporter splits the sides into individual quads though, since the normal should be constant on each side

The reason is tiny differences in the calculated normals. If the normal is rounded off (say with round(x, 6) in extract_primitives) you'll get this

master also splits based on tangents even though tangents aren't exported by default. That's fixed by #1023.

Do you think the importer should merge verts together that differ only in their UVs/normals/tangents/colors?

Do you think the importer should merge verts together that differ only in their UVs/normals/tangents/colors?

It wouldn't hurt.  There's been a lot of user confusion over why glTF does it this way, and perhaps the importer could hide all that by automatically merging the vertices.  Done correctly, it wouldn't affect the roundtrip tests, which would split apart again on export.

I blocked out a prototype for the importer: weld-verts-experiment.
It's far enough along to play around with.
Here's an example with CesiumMan. The branch manages to import it all as one piece.

Perf looks between 1.2-2.5x slower so far (only tested with small models).

So about the merging verts experiment...
I think it's basically done. I got the import time down to around 0.9-1.5x master's import time (by throwing tons caches at it lol).
Blender->glTF->Blender
The Blender->glTF->Blender roundtrip works. Originially-distinct-but-collocated verts can get merged obviously.
glTF->Blender->glTF
But the glTF->Blender->glTF roundtrip is... ehhh. The vertex count can sometimes increase or decrease.
I don't know why it would decrease, but the reason for increasing is the custom per-loop normals (ie. vertex-per-face normals). When you set normals with normals_split_custom_set, you do not necessarily get the exact same normals back out when you read them out again. So the importer can give the same normal at two loops, but when the exporter reads them out, they can be different, and so it will obviously split that vert, increasing the vert count. Rounding the normal off like I said in the first comment can help but its not enough because the difference can be appreciable.
Here's an example with 01_vertex_count_32bit. The vert in the center of blue edges (those are sharp; normals_split_custom_set marks them sharp automatically) had the same normal at all its loops when passed into normals_split_custom_set, but the actual resulting normals are visibly different.

Blender stores some complicated internal representation of custom per-loop normals (see, uhhh, this) which is why I guess this happens. And its totally down to using normals_split_custom_set (which takes a normal per loop) instead of normals_split_custom_set_from_vertices (which takes one per vertex) like master. If master is changed to set the exact same normals but using normals_split_custom_set, it has the same behavior.
So yeah, Blender seems to be able to set and read back custom normals when setting one per vert, but it doesn't do it reliably if you set one per loop, which makes merging verts not work very well.

I'm impressed by the sleuthing and the handwritten Unicode table flip.
Does the situation improve if the normals are submitted per-vertex, and then "merge by distance" is called as a post-process step?  Or does the data all end up in the same place anyway, making this unavoidable?
We don't need to stay married to tests that demand glTF->Blender->glTF perfection in terms of vertex count.  But we should make sure that this type of change is worth it to end users, as it looks like there's a speed penalty.

The reason I didn't is because we don't want to merge just by distance. That would merge collocated verts with distinct vertex groups (bone weights) for example. But if we did do that, the per loop normals don't seem to work out either.
Obviously the situation pictured above (01_vertex_count_32bit) wouldn't happen, since, like I said, everything is okay if you set per-vertex normals, and in this case no merging is happening so the merge-by-distance wouldn't do anything.
But if we look at 10_custom_normals: if you import (using master) and then run merge-by-distance, it does not produce the correct per-loop normals

I merged the initial bug fix.
Keeping this issue alive because of normals discussion on it

Let me record two more problems with setting per-loop normals.

There's a method mesh.validate() that deletes degenerate/duplicate/OOB tris and their loops. This is pretty important because Blender will crash if you give it bad tris.
It also seems to clear the custom normals (you can tell it not to but it doesn't appear to fix up the custom data to match the fixed-up mesh, which also causes crashing).
That means we need to set the per-loop normals after mesh.validate(). So we have a list of normals for each loop, right? But mesh.validate() has deleted some random loops to fixup bad geometry and we have no idea which were deleted. Out list of normals is now bad. If we try to set the normals and some loops were deleted or something, we get an exception.
With per-vert normals, this isn't a problem, because mesh.validate() doesn't delete verts.

The second problem: consider a mesh like this. It has two coincident tris and six verts (three collocated pairs). The tris have opposite normals. This would be the normal way to create a "double-sided" face when backface culling is turned on for example.

Now if we dedupe these verts, we get just three verts, and two duplicate tris (ie. two tris on the same set of three verts). Blender actually appears to be okay with the duplicate tris. But we have to call mesh.validate() (because there might be degenerate tris or something and Blender isn't okay with that) and mesh.validate() deletes the duplicate tri, turning this into a "one-sided" face.

@julienduroure @emackey How about we close this? The model from T76677 now imports as expected when using "Merge Vertices" and "Flat Shading". I think it will be easier to track anything further with specific issues.

Thanks @scurest!


test: Sr lint pr titles 159

Warnings

:warning:
Please include a description of your PR changes.

  Generated by :no_entry_sign: dangerJS against c3fdd0f9ab84c32a35cfe40ded9dfbd9b8efbaf8


FastAPI's HTTPExceptions do not get sent with the error message as subtitle

How do you use Sentry?
Sentry Saas (sentry.io)
Version
1.25.1
Steps to Reproduce

Create 2 simple FastAPI routes that raise exceptions like this:

@router.get("/http-exception")
async def trigger_http_exception():
    raise HTTPException(
        status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
        detail="Intentional HTTPException, please ignore",
    )

class MyHTTPException(HTTPException):
    """This class should be used to throw our custom HTTPExceptions,
    as the base class does not provide the error message to Sentry"""

    def __init__(self, status_code: int, message: str):
        super().__init__(
            status_code=status_code,
            detail=message,
        )
        self.message = message  # required to make Sentry display subtitles on issues

@router.get("/http-exception-cause")
async def trigger_http_exception_with_cause():
    raise MyHTTPException(
        status_code=status.HTTP_500_INTERNAL_SERVER_ERROR,
        message="Intentional HTTPExceptionWithCause, please ignore",
    )

Call the endpoint at /http-exception
Call the endpoint at /http-exception-cause
Go to Sentry's issue page, and confirm that only the MyHTTPException provides a subtitle for the issue with the error message, and the HTTPException does not.

I also contacted Sentry support and they also confirmed this is a bug.
Expected Result
Both exceptions should show the error message as the subtitle in the issue. On FastAPI HTTPExceptions this is called detail.
Actual Result
Only the custom MyHTTPException has the subtitle in Sentry issues.

I debugged printing the event on the before_send function and the event.exception.values[0].value as an empty string for HTTPExceptions:

This is not the case with our custom exceptions, that as a workaround set the message field.

Hey @nicolassanmar, thanks for opening this, it'd definitely be nice to have the detail treated the same way we do messages. PRs are always welcome if you or anyone reading this feel like giving it a shot! We could either fix this in the Starlette integration, or more generally whenever we format the exception value and there's no message, but there is a detail.

This is an excellent Issue raised! I have also encountered the same issue and am working around it with using Python's Exception class for now. But this really does need to be solved.

Status update: there's an open pull request for this, but it needs some changes and the original contributor hasn't had time -- we'll take a look at it and finish it when time permits.


chore: Update EC2nodeClass readiness if it is terminating

Fixes #N/A
Description
This PR adds a change to update EC2nodeClass readiness which would now be dependent on if the deletion timestamp is set or not.
How was this change tested?
Tested on local cluster
Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[x] No

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

19 of 21 (90.48%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.005%) to 79.028%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/controllers/nodeclass/status/controller.go
19
21
90.48%

Totals

Change from base Build<PHONE_NUMBER>:
0.005%

Covered Lines:
5969

Relevant Lines:
7553

💛  - Coveralls


Go: Make sure clientNamePrefix doesn't break on new Interfaces

Go has a logic of dropping service names when they are not necessary.
Eg, instead of "library.NewLibraryClient",
we just say "library.NewClient".
Previously we drop the service name in two situations

When the service is the only one defined in the package
When the name of the service is the same as the name of the package

This commit removes the first condition,
as it might break client libraries when new services are added
to the package later on.

Current coverage is 78.76% (diff: 100%)

Merging #522 into master will decrease coverage by <.01%

@@             master       #522   diff @@
==========================================
  Files           245        245
  Lines          8943       8942     -1
  Methods           0          0
  Messages          0          0
  Branches       1161       1160     -1
==========================================
- Hits           7044       7043     -1
  Misses         1592       1592
  Partials        307        307

Powered by Codecov. Last update 79e5583...a592305

@vchudnov-g PTAL


feat: Clear stub cache in background job

Feature Request
Describe the Feature Request
Stubs are stored, besides on the actual data location (e.g. database, file system), in an in memory cache so stubs can be retrieved quickly after the cache has been set up. Because multiple HttPlaceholder instances can be set up, a "stub cache tracking ID" will be saved so that other instances know that their local cache need to be cleared when the ID has changed. Whenever a stub is updated / deleted etc., the cache will be cleared and the stub cache tracking ID will be updated.
The problem that now sometimes occurs is that whenever multiple calls to the API are done to update / delete stubs, the cache is cleared every time after an update call. It would be better if the cache is cleared in a background job. The background job will check if the stub cache tracking ID has changed and, if this is the case, will clear the cache.
Describe Preferred Solution

Add new job that will clear the cache if applicable.
Add feature flag to enable or disable the background job. If feature is enabled, cache will be cleared in the "old" way. This should be done so that people who choose to host HttPlaceholder in the cloud in combination with a serverless database, will not pay for extra costs when the database is queried and there is nothing to delete. The feature will be enabled by default.
Make the cron expression used for configuring the background job configurable.

Describe Alternatives

Related Code

Additional Context

If the feature request is approved, would you be willing to submit a PR?
Yes / No (Help can be provided if you need assistance submitting a PR)

As I started writing the code, it seems unfeasible to do this. It would be much better if the cache would NOT be cleared if an update to the stub store is done, but simply replacing the stub in the cache and subsequently updating the tracking ID so that other instances of HttPlaceholder know they should update their own cache.


Is there a way to start a meeting without asking for video permissions?

I'm building an app that currently doesn't require nor utilize video, is there a way to not require video permissions in order to start a meeting?

Hello @john-raymon . Video permission is not required to start the meeting, but audio permission is currently needed to start the meeting. You can test it by removing Camera Permission  and Camera Permission. Also you can remove NSCameraUsageDescription from iOS to test.
Let me know if this works. Thanks.

Thank you that works!


Fix typo in out_dir of Makefile

Hello, frist of all nice work!
Noticed a typo in Make file, needs a forward slash

Hu, thanks for the PR 🙂
But this isn’t a typo. I prefer hidden folder convention for binary and object file directories as to differentiate from actual source content


Update LOBPCG following enhancements in SciPy 1.11

https://github.com/scipy/scipy/pull/17675
Currently, some tests are skipped as a workaround.: https://github.com/cupy/cupy/pull/7924

I would like to help with this.

While I'm not a CuPy dev, I am pretty sure that while the main cupy namespace is wrapped by array-api-compat, cupyx.scipy.sparse isn't. This makes sense given that scipy.sparse is itself not wrapped. I will comment on the SciPy issue linking to relevant discussion for the scipy.sparse side.

Hi @lobpcg, thank you for offering help! As @lucascolley suggested, only NumPy part is supported by Array API.
Support for the solver was originally added to #4281 based on the SciPy code at that time, and now lives at https://github.com/cupy/cupy/blob/main/cupyx/scipy/sparse/linalg/_lobpcg.py.


Fts/484 account storage alert

Storage view

@lmcmz I fixed many of the change requests, but I have a few questions, the most important of which is where to show the alert view, as I can't find any other root view

@lmcmz
This is how it appears to me... what are you using? Is that a simulator?

Let's merge this first, and make the fix in following PR


Document expected structure of project in readme

It was observed https://github.com/rust-practice/cargo-leet/pull/84 that right now the expected package structure expected by the tool is not documented in the readme.

@c-git

Given the discussion in the conversation of this PR we need to decide how we want to handle this. One other other option I was thinking about is we have a config file in the user's home directory which tracks the most recent problems they worked on and we could get the most recent one from there. I can help with implementation if this seems daunting.

That said the easiest option is to have the user specify the problem but I'm concerned about the UX of that option. I feel auto complete may actually make specifying the file not that hard but they would have to think about what the problem number or name is and this might just end up being harder than just doing the copy and paste themselves.

I still think that one project per solution is the ultimate solution to this problem. Here's why:

Having multiple solutions in the same project/package will require the user to enter the wanted solution every single time.
Caching isn't a good option since if it's there people including me will want to use it, but can't since it's unreliable and the name of a previously used solution might still be stored inside. That means that everybody will manually enter the wanted solution on the first run, so why can't they just up arrows in their shell? This makes this option useless.
Leetcode only allows one file per solution, not even allowing external dependencies. And having multiple completely unrelated Rust files in the same directory is very confusing.

Implementing this would require a major rewrite, but I'm willing to do it

This issue is only for documentation not really a proposal to change the structure but we can discuss it here.
I acknowledge that the feature in PR https://github.com/rust-practice/cargo-leet/pull/84  becomes less useful if there are multiple solutions in the same folder.
Do you not keep your old solutions? I think that is the assumption that is causing the mismatch. I keep my old solutions for reference and there are 3 other ppl using it and they all use it the same way as me (keeping their past solutions).

Having multiple solutions in the same project/package will require the user to enter the wanted solution every single time.

Yeah that's true and I'm not sure there is any way to get around it as some people do want to keep their previous solutions.

Caching isn't a good option since if it's there people including me will want to use it, but can't since it's unreliable and the name of a previously used solution might still be stored inside. That means that everybody will manually enter the wanted solution on the first run, so why can't they just up arrows in their shell? This makes this option useless.

I agree it is complicated and may not be reliable. I think we can rule out this option then.

Leetcode only allows one file per solution, not even allowing external dependencies. And having multiple completely unrelated Rust files in the same directory is very confusing.

Yes that's correct but they do allow a fixed set of dependencies and we need to also depend on the library version of this crate to do the tests. And to set the rust version. The other files are all related to leetcode that is the common connection.

Implementing this would require a major rewrite, but I'm willing to do it.

Not sure what you mean by this in that sentence.

Pretty much nobody uses the program right now.

I don't use it often but I do use it. And while the others are not active they also use it.

It is as simple as copy/pasting.

You mean for the migration to separate projects for each solutions?

Why would anyone want to rerun old Leetcode code? It's for learning.

Yes I return to the old ones as references for things I've done before and to see how I did them and to improve on them over time. If you look at my repo you'll see that from time to time I'll do a problem I've done before and modify it to incorporate things I've learned since I'd done it the first time.

I think we need to deal with all the commands in the program which now include New added in https://github.com/rust-practice/cargo-leet/pull/89 and as such I don't think this separate ticket is needed anymore as users are able to see the expected structure somewhat from https://github.com/rust-practice/cargo-leet-template and I don't think there is value in keeping this issue open any longer.


Does not working with grunt-newer

I am using this with grunt-newer.
When running the command newer:imagemin it resizes the image the first time as expected. However, on the second run through it still minifies the original images.

grunt-newer does not work with this plugin.
https://github.com/tschaub/grunt-newer/issues/new

Then you may want to remove this from the Readme We recommend using grunt-newer to only process changed files as minifying images can be quite slow.


Simple Paging Endpoint for GraphQL/Metadata API

I took a simple approach for now, unlike Pager which takes an endpoint and works some magic, this just runs a query and collects the results.

Note, I thought of a way to do testing based on https://requests-mock.readthedocs.io/en/latest/response.html#response-lists

Ok getting those tests in there was an adventure. I still don't do any error checking on nth calls, only the first. I'll think about if that matters, or for not just make this endpoint "all or nothing"


feat(lesson-counts): add correct lesson count for units with sensitiv…

…e and expired lessons
Description
Music year: 1985

List of changes

Unit Listing Page

Navigate to Year 7
Click Art and design
Confirm lesson count is displayed correct (not counting unavailable lessons)

Lesson Listing Page

Navigate to Year 7
Click Art and design
Click Unit 2 Pop art
Confirm lesson count is displayed correctly (should be 3)

[x]  New lessons heading count does not include is_sensitive lessons
[x]  Lesson count in unit list component does not include is_sensitive lessons

Issue(s)
Fixes #
How to test

Go to https://deploy-preview-2542--oak-web-application.netlify.thenational.academy/pupils/programmes/art-secondary-year-7-l/units/pop-art-modern-popular-culture-4928/lessons

You should see correct lesson count

Go to https://deploy-preview-2542--oak-web-application.netlify.thenational.academy/pupils/programmes/rshe-pshe-secondary-year-9-l/units/

You should see correct lesson count

Screenshots
How it used to look (delete if n/a):
{screenshots}
How it should now look:
{screenshots}
Checklist

[ ] Added or updated tests where appropriate
[ ] Manually tested across browsers / devices
[ ] Considered impact on accessibility
[ ] Design sign-off
[ ] Approved by product owner
[ ] Does this PR update a package with a breaking change

@benprotheroe looking good on the lesson listing page - the counts are correct. The only slight issue is we know show 0 lessons on the unit page for unavailable lessons rather than not displaying anything at all. Can this be changed back at all? See screenshots
Old:

New:

:tada: This PR is included in version 1.473.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Timeline feature does not respect security constraint set by "add-group-repo" kie-cli command

Depends on https://github.com/droolsjbpm/kie-uberfire-extensions/pull/9.

fixing.

Licenses!

@csadilek  ready to merge!

+1 to merge.

checking....

@psiroky  "Problem copying files : No space left on device"

Updated: https://github.com/droolsjbpm/kie-wb-common/pull/139


Update AboutUs

Each member to add profile photo in /docs/images/
Update /docs/AboutUs.md with roles and responsibilities.

Fixed by #3 #6 #7 #8 #9 #10 #11 #12


switchCamera doesn't work on the latest version

switchCamera doesn't work on the latest version
Platform: Android
react-native-agora verison: 3.6.2
react-native version: 0.66.3

is our example working?

same in version 3.7.0

Caused by conflict with another library. In my case, the other library is using the front camera, so it won't be able to switch to the back camera. Closing this issue for now.


Fix doc menu and search being hidden on mobile

We might need to enable TOC on all pages to maintain the original mobile menu design.

I just noticed the missing index toc. That's odd, I wonder why it's just happening on that page.

@ravindk89 @djwfyi There is no TOC available on the index and some other pages. Have we set it disabled in the configs?

Ah, I see the issue with index.rst
The included conditional file header levels do not match properly with the actual page being included, and that's causing issues.
I can handle that in a separate PR - I would benture if other pages are also missing a TOC, its due to a mismatch in header levels within a conditional include.


Fix README.md

README.md is bad. Fix it.

Not completely up to date. I am going to update each branch's README.md. Issue will be open a while as I will need to overhaul the README many times until first release.

Read me does not mention pip installing packages.

I am going to try to redo the readme soon. It should include how to install the python packages used in the program, and also how to install sqlite3.

README.md screenshots are now out of date.

I've  updated the README.md quite a bit tonight and in the past update (v0.8.5).

I've added more in dev build as well for next release.

Dev was pushed to main in v0.8.5. Updated instructions are now in main branch for README.md. Keeping this open till v1.0.0 so I can ensure documentation is up-to-date for full release.

Part of README.md is broken, I will fix this tomorrow. I am feeling lazy right now and will do it tomorrow.

README.md needs updated for MacOS. Thanks to @tylermichaelsen for finding this.
I have an iMac Mini I can test on, so that I can update the documentation to be correct.

I'll test more on MacOS on Sunday when I work more on this project. I will also take care of fixing the error in the current README.md as I did not fix that this past week either.

Testing more on MacOS. Need some testers for different Linux distributions (if I cannot find anyone, I will load VMs). Program works on Fedora 40.
Need to update README.md to reflect the different install processes between Operating Systems...

Added instructions for Linux. Still need to fix photos and finish Macintosh setup/configuration...

#72 is a duplicate. I will take care of the images before v1.0.0.
To do:

Update images
Add Linux instructions
Add MacOS instructions


Dragonrise USB-Generic Gamepad will not work

Gamepad runs in emulator but not in emulationstation.
"NO GAMEPADS DETECTED"

Detects just fine for me
Adri Idzwan Mansor
General Manager
Iron Ore Division
Malaysian Coal & Minerals Corporation Sdn Bhd
On Sat, Feb 28, 2015 at 6:04 PM, 5ilv4n0<EMAIL_ADDRESS>wrote:

Gamepad runs in emulator but not in emulationstation.
"NO GAMEPADS DETECTED"
—
Reply to this email directly or view it on GitHub
https://github.com/Aloshi/EmulationStation/issues/407.

In my case, Dragonrise works in pcsx, but not in emulationstation.

Sounds like an issue with your distro.
To quote Aloshi from another thread which may work for you - "Try adding  to your $HOME/es_settings.cfg and see if that helps at all."

I'm also having an issue, and I'm not sure if it's related to my Dragonrise USB-Generic Gamepad.  I can use emulationstation just fine, but can't seem to get the emulator to go.  It exits immediately back to emulationstation.  Running the same command in the terminal appears to work fine.

@zo0o0ot Does this happen for all emulators? Which platforms are you specifically trying ?

I thought it happened for all emulators, but I was able to get some running eventually.  It could just be that I have bad emulator commands set up in the es_systems file.  I'll try to get you a full list of what's working and what's not the next time I'm in front of the machine.  My issues may be user error, and if that is the case, I apologize for taking up your time.


SW-2912 Return active accessions per storage location

The UI needs to show the number of active accessions in each storage location.
Include it in the GET API responses.

Current dependencies on/for this PR:

main

PR #952

PR #954   👈

This comment was auto-generated by Graphite.


Link not clickable on Whatsapp

I just realised that with some devices the link myapp.app.link is not clickable through Whatsapp, it's only clickable when it has http/https before.
Is there any way to fix this?

Hello,
Thank you for reaching out.
Unfortunately, this is a limitation of WhatsApp. The WhatsApp app will not recognize the app.link top level domain. This makes the links unclickable unless you add the https/http protocol.
We have reached out to WhatsApp's dev team numerous times in the past year to get this fixed. We will continue to do so since it is still impacting partners like yourself.
In the meantime, you will either have to share your deep links with the https/http prefix or switch your link domain to a .com or other top level link domain. This will make your deep links clickable in Whatsapp.
I apologize for this inconvenience. I have updated the Github readme to reflect this linking behavior within WhatsApp.
Thanks,

Hi @ethanneff and thanks for your comment.
I tried Branch but as I explained a few days ago in other post I only can get the main url. If I need to redirect the user to myApp/options I can't get that info.
That's weird because with my Android phone it works well with every single link. Maybe the Whatsapp's team dev struggles as well with Android's team... who knows.
So apart from Branch solution is there any other way to get this working through Whatsapp (because being honest the 80% of our link will be there)?
Cheers

There is an issue with http/https deeplink  if we send these on any app it will open popup open with in android and ask for open in chrome or our app and if user open in chrome our app will not trigger..

There is an issue with http/https deeplink  if we send these on any app it will open popup open with in android and ask for open in chrome or our app and if user open in chrome our app will not trigger..


Do we need this local object grpc_core::ExecCtx exec_ctx; in src/core/ext/transport/chttp2/server/insecure/server_chttp2.cc

I am working on QNX ARM platform. I am able to compile and generate the binaries successfully.
When I try to use these binaries to run the gRPC server, I am getting a coredump as below:
#0  0x0000000f8969ffe4 in grpc_combiner_continue_exec_ctx () at /local/mnt/workspace/temp/grpc_for_qnx/src/core/lib/iomgr/combiner.cc:184
#1  0x0000000f896482a8 in grpc_core::ExecCtx::Flush (this=this@entry=0x441c3a360) at /local/mnt/workspace/temp/grpc_for_qnx/src/core/lib/iomgr/exec_ctx.cc:156
#2  0x0000001cab04af80 in grpc_core::ExecCtx::~ExecCtx (this=0x441c3a360, __in_chrg=<optimized out>) at /local/mnt/workspace/temp/grpc_for_qnx/src/core/lib/iomgr/exec_ctx.h:124
#3  grpc_server_add_insecure_http2_port (server=<optimized out>, addr=0x7fd50f111 "<IP_ADDRESS>:62472")
    at /local/mnt/workspace/temp/grpc_for_qnx/src/core/ext/transport/chttp2/server/insecure/server_chttp2.cc:31
#4  0x0000001cab032658 in grpc_impl::Server::AddListeningPort (this=0x7fd535bd0, addr=..., creds=0x7fd4dd6d0)
    at /local/mnt/workspace/temp/grpc_for_qnx/src/cpp/server/server_cc.cc:1199
#5  0x0000001cab03082c in grpc_impl::ServerBuilder::BuildAndStart (this=this@entry=0x441c3a758) at /local/mnt/workspace/temp/grpc_for_qnx/src/cpp/server/server_builder.cc:411
#6  0x0000001cab026874 in qaic::QMonitorTaskStarter::startGRPCServerHelper (this=0x441bb9950, config=..., readyStatus=..., asyncTestSupport=false)
    at /local/mnt/workspace/qnx/runtime/lib/qmonitor/src/QMonitorTaskStarter.cpp:89
#7  0x0000001cab02a9b8 in std::__1::__invoke<void (qaic::QMonitorTaskStarter::*)(qaic::QMonitorGRPCTaskConfig const&, std::__1::promise<QStatus>, bool), qaic::QMonitorTaskStarter*, qaic::QMonitorGRPCTaskConfig, std::__1::promise<QStatus>, bool, void>(void (qaic::QMonitorTaskStarter::*&&)(qaic::QMonitorGRPCTaskConfig const&, std::__1::promise<QStatus>, bool), qaic::QMonitorTaskStarter*&&, qaic::QMonitorGRPCTaskConfig&&, std::__1::promise<QStatus>&&, bool&&) (__a0=<optimized out>, __f=<optimized out>)
    at /local/mnt/workspace/QNX_TARGET/qnx7/usr/include/c++/v1/__functional_base:382
#8  std::__1::__thread_execute<void (qaic::QMonitorTaskStarter::*)(qaic::QMonitorGRPCTaskConfig const&, std::__1::promise<QStatus>, bool), qaic::QMonitorTaskStarter*, qaic::QMonitorGRPCTaskConfig, std::__1::promise<QStatus>, bool, 1ul, 2ul, 3ul, 4ul> (__t=...)
    at /local/mnt/workspace/QNX_TARGET/qnx7/usr/include/c++/v1/thread:337
#9  std::__1::__thread_proxy<std::__1::tuple<void (qaic::QMonitorTaskStarter::*)(qaic::QMonitorGRPCTaskConfig const&, std::__1::promise<QStatus>, bool), qaic::QMonitorTaskStarter*, qaic::QMonitorGRPCTaskConfig, std::__1::promise<QStatus>, bool> > (__vp=0x7fd50f490)
    at /local/mnt/workspace/QNX_TARGET/qnx7/usr/include/c++/v1/thread:347
#10 0x0000000f8900b4e0 in pthread_attr_setdetachstate ()
   from /local/mnt/workspace/QNX_TARGET/qnx7/aarch64le/usr/lib/ldqnx-64.so.2
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

After investigation I root caused the issue.
In file src/core/ext/transport/chttp2/server/insecure/server_chttp2.cc one local unused object is created grpc_core::ExecCtx exec_ctx.
When destructor of this object is called, we are getting a crash. Even this object is not been used in this function.
My suggesting to remove this line. Let me know if my suggestion is correct, because I am new to gRPC code.

Hi, exec_ctx sets up a thread local context that is used by gRPC Core internals, and so even though it is unused in this function, it is still "used". Please continue your investigation. It's much appreciated!

Thanks @yashykt for your response. Please let me know if I remove the line, what will affect(with some good example).
Because I am not sure the functionality of the thread local context, which is used by gRPC core internals. If you know any use case which can prove that this is required then please help me to test it and let me know.
Also I am facing the issue "DNS server could not find", when try to run the helloworld "greeter_client". I was worried that, I may have disable the functionality by such code change.
Thank you again.

We've got a bunch of tests in the test directory. I'm pretty sure something or the other would break. I think what you need to check is what is causing the coredump.
ExecCtx is mostly used as a way of scheduling closures in gRPC Core. If you search for ExecCtx::Run you would see it being used quite frequently.

The core dump is occurred in function grpc_combiner_continue_exec_ctx () at   line:
grpc_core::Combiner* lock = grpc_core::ExecCtx::Get()->combiner_data()->active_combiner;
I checked what is NULL, and found that grpc_core::ExecCtx::Get()->combiner_data() = NULL.
I tried to put the logs, where this variable are set, but its not hitting any of the code.
Help me to debug this, if you can.

My code is simple as below, (After following the helloworld and async code)
  std::string serverAddr =
      qaic::qmonInetAll + ":" + std::to_string(config.port);

  GRPCService service;
  MonitorService::Service *monitorService = &service;
  ServiceExt::Service *monitorExtService = &service;

  service.init();

  ServerBuilder builder;
  builder.AddListeningPort(serverAddr, grpc::InsecureServerCredentials());

  notification_queue_ = builder.AddCompletionQueue();
  client_queue_ = builder.AddCompletionQueue();

  builder.RegisterService(monitorService);
  builder.RegisterService(monitorExtService);
  builder.RegisterService(&monitorAsyncService_);

  server_ = builder.BuildAndStart();
  LogInfoG("Server listening on {}", serverAddr);

  // Queue a connect wait request
  initClientSink();

  // start 2 threads for receiving messages.
  clientConnectThread_ =
      std::thread(&QMonitorTaskStarter::startClientConnectThread, this);
  notificationThread_ =
      std::thread(&QMonitorTaskStarter::startNotificationThread, this);
  if (asyncTestSupport) {
    type2MsgGenThread_ =
        std::thread(&QMonitorTaskStarter::genType2Messages, this);
  }

  readyStatus.set_value(QS_SUCCESS);

  server_->Wait();
  // Kill threads and wait for them to exit
  notification_queue_->Shutdown();
  client_queue_->Shutdown();
  // The threads should exit once a trycancel is called
  // on every client
  clientConnectThread_.join();
  notificationThread_.join();

@yashykt any hints for me?

combiner_data() simply returns the address of combiner_data_ which is a part of ExecCtx object. Given that the stack trace shows that we are in the destructor of ExecCtx, the object definitely exists but it looks like for some reason it wasn't set in tls properly.
This can happen due to a few reasons -

TLS is using the wrong configuration. We have a few implementations of tls depending on the platform in src/core/lib/gpr/tls_*. I think the first thing to do here would be to verify that whatever implementation is being used actually works for your system.
This would be an init/shutdown issue where for some reason gRPC is being shutdown before your code is done with gRPC. To work around this, you can call grpc_init() at the start of your code and grpc_shutdown() at the end.

Thanks @yashykt for you response. Previously I was using GPR_GCC_TLS after debugging this I found the same issue as you mention in point 1, so I changed to GPR_PTHREAD_TLS. Now it seems no crash, but now it is hang at BuildAndStart() function.


Sync validation not triggered after reset

Bug Report
Sync validation is not triggered after a form is reset.
What is the current behavior?

Focus on username field.
Hit Tab.
Error message is shown.
Reset form.
Focus on username field.
Hit Tab.
Error is not shown under the user field.

What is the expected behavior?
Sync validation should happen even tho the form was previously reset.
Sandbox Link
Reproduction Code
What's your environment?

Redux Form: 7.0.3
OS: macOS Sierra 10.12.6
Browser: Chrome 60

Other information
Looks very similar to #2838

Thank you, though your expected and actual are the same? Validation is running, but it's also passing in your reproduction steps. If I add required to age for example, submit is prevented?

Just updated the comment. After focusing out of the username field the second time (after the form has been reset). The error is not shown beneath it.

I have the same problem with my own project :(

Yep, same problem...

Same behavior when mount/unmount form.
Current behavior:
1 Mounted form
2 Submit
3 Error message is shown
4 Unmount form (for example form in modal)
5 Mount form
6 Submit
7 Error is not shown under the user field and "@@redux-form/SET_SUBMIT_SUCCEEDED";
value is {};
props .dirty == false

A simple fix is having the reset button disabled if the form is pristine. For some reason that solves it.

This one might be an easy fix: @@redux-form/UPDATE_SYNC_ERRORS should be dispatched after @@redux-form/RESET
state when form is first initialized

state diff after form is reset

as you can seee, form.fieldLevelValidation.syncErrors gets cleared

Closing as a duplicate of #2971. This seems a legitimate bug, PR's welcomed!


pr/christarazi/fix phantom node metric

node/manager: Add info logs for added and deleted nodes
health/server: Fix stale references to old nodes during health probe

Related: https://github.com/cilium/cilium/pull/28382

cc @derailed @tommyp1ckles JFYI

/test


style: organizer map container need style text

beginning to implement semantic commits. :
makes it much easier to lookup in gitGraph

styled slug page, 75% done

blockage: centering organizer name <Text>

update README.md with contributor section

update Package.json with keywords and description

add custom Hook useMediaQuery from NextUI documentation to return boolean from passed in param width: Number

this should be used in ternary operations to determine breakpoints if NextUI component API doesn't already have it built in


Types change: Payload(s) [POST/GET]: signers (null | string[])

TL;DR:
Payloads have a new meta property: signers. The field can be null or an array containing between one and an arbitrary amount (currently hard capped by our backend at four, client doesn't have to enforce) XRPL account addresses.
When one or more account addresses are entered, XUMM forces signing with one of those accounts.
Impact:

[x] Payload GET types (meta.signers) (null or string[])
[x] Paylost POST types (options.signers) (omit, null or string[])

Commit to XUMM-SDK:
https://github.com/XRPL-Labs/XUMM-SDK/commit/8b5c484b23f774de70bcd3c6d95e87dd99d968b4
Based on discussion:
https://github.com/XRPL-Labs/XUMM-Issue-Tracker/issues/384#issuecomment-1075098922

GET: https://github.com/XRPL-Labs/xumm-sdk-py/commit/cc4e5b7239fc45dbce1af667edcf1e5a42002e6b
POST: https://github.com/XRPL-Labs/xumm-sdk-py/commit/dbe040f409ffc5f918086a12f190ef289e709d22

Thank you!


refactor code to remove dependency on THC/THCDeviceUtils.cuh

THC was deprecated in pytorch >= 1.11. Replaced THC class functions with C10 and ATen functions for compatibility with pytorch >= 1.11.

Worked perfectly for me with the following!
  - python=3.8
  - cudatoolkit=11.3
  - pytorch=1.12.1

This worked for me as well, and let me use modern versions of PyTorch with the 100 DoH detector. Thank you!