runtime: wasm GC causes stop the world for a very long time

What version of Go are you using (go version)?

$ go version
go version go1.19 linux/amd64

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/user/.cache/go-build"
GOENV="/home/user/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/user/.go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/user/.go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go-1.19"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go-1.19/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build306969192=/tmp/go-build -gno-record-gcc-switches"

What did you do?
I am working on a hobby game engine that has both Native (OpenGL) and WASM (WebGL2) support.
When running a larger scene in WebAssembly I notice that whenever a GC is triggered it causes everything to freeze for about a second or more.
Actually, it happens with smaller scenes too but just less often (due to GC triggering less often). I think that the duration of the freeze is proportional to the number of active pointer references but this needs more testing to verify.
I try not to allocate much memory but it happens that once a frame I might allocate a few KBs here and there (I have a custom react-style Go UI framework that is hard to make allocation-free due to tree invalidation logic and besides, one should be able to make use of Go's memory management). This means that after 15s-60s everything just freezes.
I managed to write a dummy program that reproduces the issue:
var (
	statsRunning int32
	gcStats      = new(debug.GCStats)
	cached       []byte
)

func main() {
	// Force the GC to trigger more often. If you remove this, you might need
	// to wait up to a minute in some cases.
	debug.SetGCPercent(5)

	aLotOfData := make([]int, 20_000_000)
	aLotOfRefData := make([]*int, 20_000_000)
	for i := range aLotOfRefData {
		aLotOfRefData[i] = &aLotOfData[i]
	}

	callbackFunc := js.FuncOf(func(this js.Value, args []js.Value) any {
		frameStart := time.Now()

		// Check stats once in a while.
		if atomic.CompareAndSwapInt32(&statsRunning, 0, 1) {
			go func() {
				debug.ReadGCStats(gcStats)
				if len(gcStats.Pause) > 0 {
					log.Printf("GC STATS! Total: %d; Time since last GC: %s; Pause total: %s; Pause last: %s",
						gcStats.NumGC,
						time.Since(gcStats.LastGC),
						gcStats.PauseTotal,
						gcStats.Pause[0],
					)
				}
				atomic.StoreInt32(&statsRunning, 0)
			}()
		}

		processingTime := time.Now()

		// Do some processing so that the frame takes some time and so that the
		// runtime is forced to go through a lot of pointers (not sure if relevant).
		for i := 0; i < len(aLotOfRefData); i++ {
			*aLotOfRefData[i]++
		}

		// Couldn't figure out a better way to force the compiler not to optimize
		// the slice allocation. Hence keep it in a variable and use it next frame.
		if cached == nil {
			cached = make([]byte, 1_000_000)
		} else {
			for j := range cached {
				cached[j]++
			}
			cached = nil
		}

		processingDuration := time.Since(processingTime)

		log.Printf("Frame time: %s (processing: %s)", time.Since(frameStart), processingDuration)
		return nil
	})

	intervalFunc := js.Global().Get("setInterval")
	intervalFunc.Invoke(callbackFunc, 1)

	<-make(chan struct{})
}

What did you expect to see?
Smooth and consistent logging in the Browser Console.
What did you see instead?
A stop the world situation once in a while (every 2 seconds or so). The Total counter (indicating the number of GC runs) always increases immediatelly after the freeze, showing that it is related to GC.
What's interesting is that none of the stats (even the frame time) indicate that GC took more time than indicated but the fact is that the Browser freezes. Could it be that Go is doing something that JS or the Browser does not like and needs to adjust to once setInterval callback has completed (e.g. memory shuffling or something of the kind)?
This is reproducible with both Chrome and Firefox. Have not tried other browsers.

Sorry for the incredibly late response to this. I assigned it to myself and then forgot. :(
I'm frankly a bit surprised that you're seeing freezes of up to 2 seconds or more.  There's a worker goroutine that might start running when there's nothing else to run, but for the most part the main application thread will just do GC work as it allocates memory. The GC is almost fully concurrent, so the metrics you're reading aren't going to fully represent the time the GC took away from the main application thread. (The pauses are relevant, but the time since the last GC isn't really all that useful.)
There's the runtime/metrics package, and we could try dumping some of those stats. I suppose it's possible that if the application runs for quite a bit of time before yielding to the background GC goroutine that that goroutine might end up hogging some time. Now that I think of it, that does seem somewhat plausible.
Unfortunately I'm having some trouble reproducing locally with Node.js. It looks like the setInterval callback isn't firing? (Nothing is failing; I did have to replace the blocking channel recv at the end there with a Gosched loop though, otherwise the deadlock detector fires since it's not aware of the callback... I would've figured we disabled that for Wasm.)

Hi @mknyszek ,
It's been a while since I have reported this. Since then I have reduced my memory allocation during frames a lot and so this has not been visible much anymore. The problems I have been facing since are more related to https://github.com/golang/go/issues/39740.
That said, I will try to reproduce this in the following days and will write back with information. It is possible that something has changed in Go or in browser's handling of WebAssembly and that this issue is not valid anymore.

@mknyszek ,
I am still able to reproduce it with the example code I have provided above. Running it and looking at the code, I can always see a freeze around when a GC occurs. I have adjusted the code to print millisecond precision.
Following is a screenshot of the logs when running in Firefox:

Following is a screenshot of the logs when running in Chrome:

In both cases a freeze of around one second can be observed, though the GC stats don't indicate as much.
I will run some browser performance analysis to see if something is reported there.

Here are a few browser measurements, though I admit I have a hard time reasoning about some of those.
Bottom-Up Self Time:

Bottom-Up Total Time:

Memory Summary:

This one has spikes that are at an interval similar to the freezes.
Call Tree:

Pause history:

The last one shows only ~1 millisecond times. Nothing close to the 1+ second freeze I experience.
I will try and plug into runtime/metrics one of the upcoming days.


Cannot deal with background change

I just take a picture using my phone to get a background. And at the same position, I take another picture including my upper body. The demo you provided cannot produce a good result. I think the background just has small changes which are very common in real applications and the background is not complicated. Hope you can make it more applicable :）

It is designed for matching backgrounds. For the best result use a tripod. For small motion handheld, you can preprocess the image for alignment and then pass it through the model. inference-image.py has --preprocess-alignment argument.

It is designed for matching backgrounds. For the best result use a tripod. For small motion handheld, you can preprocess the image for alignment and then pass it through the model. inference-image.py has --preprocess-alignment argument.


PEP 517 integration

The recent PEP 517 specifies an interface for alternative build systems to be defined, which is exactly what's happening here.
To do that, pyo3-pack would need to provide a very simple Python interface with the following hooks:

build_wheel to build a wheel
build_sdist to build a gztarred archive of the source code
(actual semantics are defined in the PEP).

Then, releasing the pyo3-pack module to PyPI would allow users to specify the build system in pyproject.toml, making it easier to build a Rust wheel without setuptools.

I've tried implementing PEP 517 and also written a bit about that in the blog post, but it failed because pip hasn't implemented that interface yet. The current status is that you can build source distributions with disabled sdist feature, but can't install them. Writing and testing the PEP 517 interface is also blocked on pip, especially since I expect the implementation to differ from the PEP.

Yes I stumbled on your blog post after opening the issue :wink:
Setuptools already has an implementation although I'm not sure if it's really used anywhere.

I've implemented the wheel part of PEP 517 in 671fcdb5dd00c5a71fa513c4b7ed39ce601f5a55, which also contains an untested sdist writer. The implementation uses the subprocess-solution.
I've filed https://github.com/tox-dev/tox/issues/1344 for isolated builds with tox.

I've finished sdist support in 78c516f and published a beta version with the (as far as I tested) complete PEP 517 support. Testing and experience reports with the new beta are welcome! The usage is documented in the readme, even though you need to specify pyo3-pack==0.7.0-beta.1 instead of just pyo3-pack.

Hi @konstin!
Thanks for your work on this :)
I've been playing with https://github.com/indygreg/PyOxidizer, and I wanted to bundle an application that uses a pyo3-packed rust library in it's deps.
PyOxidezer doesn't support wheels, so it was a good time try out sdist.
Unfortunely pip is really bad when it comes to unicode (https://github.com/pypa/pip/issues/6566)
I've created a pyproject.toml file like:
[build-system]
requires = ["pyo3-pack>=0.7.0-beta.1", "toml"]
build-backend = "pyo3_pack"

and tried to pip install .

It seems to be this line:
https://github.com/PyO3/pyo3-pack/blob/master/pyo3_pack/__init__.py#L114
Which blows up because of the emojis in the output (windows doesn't like emojis yet).

WDYT?

Thank you for testing @omerbenamram! Seems I've got bitten by windows default encoding not being utf8 once. That should be fixed in e7a6a090cc0b75cce0b3c3393752b5b7eb8054b5, and I've published 0.7.0-beta.2 with the fix.

I see building the .tar.gz requires pyproject.toml. If it's not specified, pip complains setup.py can't be found. Perhaps you can either error on build, or include it automatically, to avoid publishing broken artifacts?

I notice that if target/wheels doesn't exist, then pyo3-pack build` fails with:
🔗 Found pyo3 bindings
🐍 Found CPython 3.7m at python3.7
💥 pyo3-pack failed
No such file or directory (os error 2)

I need to first create it via build --no-sdist.

@ijl Could you explain how you got a .tar.gz? I thought I checked for a pyproject.toml before building a source distribution.
Re the second issue: Good catch, I'll fix that.

@konstin pyo3-pack build --release --strip, then pip install target/wheels/....tar.gz. It would be nice to not need to build the wheel, too. Maybe --format bdist,sdist (by default) or something instead of --no-sdist?

target/wheels missing should be fixed with 027c33e6ec59d0169eba6bdb311ec3f375ed41a4

Thanks for fixing that. Oh, and I mean there was a pyproject.toml present, but my error was not having it include in Cargo.toml.

Oh, I see now. I've add a check in dd712c7ea1ab620297359e95761eedd4942ad7df. Thanks for reporting that!

@konstin It's now a UnicodeEncodeError 🤔

@omerbenamram I've tried another workaround for the encoding errors in #153, which makes it pass on machine (German / cp1252). It still prints a warning however about the output not being cp1252 and print surrogates instead of emoji, even though the terminal supports utf8.

It would be nice to not need to build the wheel, too. Maybe --format bdist,sdist (by default) or something instead of --no-sdist?

@ijl Could you explain the use case for only building an sdist?

@konstin I want to have a test in which I build an sdist and install it via pip. Building the project twice would be unnecessarily slow.

I see this as working well.
I think it would be prudent to make the documented usage build a non-manylinux release wheel with pinned versions:
[build-system]
build-backend = "pyo3_pack"
requires = ["pyo3-pack>=0.7<0.8", "toml>=0.10,<0.11"]

[tool.pyo3-pack]
cargo-extra-args = "--release"
manylinux = "off"

@konstin it works! sweet :)

@konstin I want to have a test in which I build an sdist and install it via pip. Building the project twice would be unnecessarily slow.

Is there a reason not to use tox with build isolation, which builds an sdist before building a wheel, or pip install .? Or could you reuse the sdist from the initial project build? The functionality for just building a wheel is already implemented as part of the PEP 517 backend, but apparently there's no way that pip will give you an sdist. Maybe a pyo3-pack sdist command would be the best solution for now.

I see this as working well.
I think it would be prudent to make the documented usage build a non-manylinux release wheel with pinned versions:
[build-system]
build-backend = "pyo3_pack"
requires = ["pyo3-pack>=0.7<0.8", "toml>=0.10,<0.11"]

[tool.pyo3-pack]
cargo-extra-args = "--release"
manylinux = "off"

I've changed the implementation to always use release mode and opened a thread on the python discourse on the topic. I've also exposed the strip option. Having manylinux = "off" is definitely a good idea; I've also added that.

I have it right now as pyo3-pack build and pip install target/wheels/*.tar.gz, which reuses the initial build's sdist artifact. I'm not using tox, and to run  pip install . would verify the repository has all the files it needs but not that the sdist does. pyo3-pack sdist would be useful, but for me this is also good enough now.

I've created https://github.com/pypa/pip/issues/6669 for solving this properly in pip.

beta.5 works perfectly for my use case, including pyo3-pack sdist. Thank you for adding that.

Thank you all for the beta testing and the feedback!
The only thing missing is the tox integration, which fails due to a bug in tox; I've opened #176 to track that. For everything else that comes up, please open a new issue.


Release

Hi,
Is there any chance of a patch release with the latest changes? Specifically cdf3df93eb0122a6b805f6592acdba58e8bd3a88 is what I've just hit.
Thanks!

Ah! Sorry about that. v2.3.1 released


Revert "Revert "tools/ci: patch for gcc-arm-none-eabi to 11.3.Rel1 August 08, 2022""

Reverts apache/incubator-nuttx#7299 since the out of docker storage is fixed by https://github.com/apache/incubator-nuttx/pull/7323

we need to submit the patch file fist to ensure that the script can be downloaded from github normally:
https://github.com/apache/incubator-nuttx/pull/7379


[DeepRec] Allow user set cpusets for each session_group.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Wired up dialogs with action, blocking, overlays

Approved! It's working perfectly, thanks for fixing this up so well 😄

Approved


Withdraw issue

Please how do I withdraw my balance from my Zen wallet because there is no withdraw icon on the dashboard of the App

Hi @Rasaki001
You may see the withdraw button following clicking on the plus sign in the main dashboard, and then click the send button. Please follow the images as reference.
Let me know if I cleared your doubt, and please if you need any additional support we will be glad to provide you support via our Helpdesk at (support.horizen.global)


Bitbucket Server Formatter defaults to port 80 and can't be changed

Hi, I am trying to make pronto work with our internal Stash installation but it doesn't seem to connect to our server. I've tried to trace the errors by looking at the stack trace and it looks like it just assumes port 80.
Here is my stacktrace:
$ pronto run -f bitbucket_server_pr -c origin/develop                                                  [2.3.1]
/Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/net/http.rb:882:in `rescue in block in connect': Failed to open TCP connection to :80 (Connection refused - connect(2) for nil port 80) (Errno::ECONNREFUSED)
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/net/http.rb:879:in `block in connect'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/timeout.rb:101:in `timeout'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/net/http.rb:878:in `connect'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/net/http.rb:863:in `do_start'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/net/http.rb:852:in `start'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/2.3.0/net/http.rb:1398:in `request'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/httparty-0.14.0/lib/httparty/request.rb:118:in `perform'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/httparty-0.14.0/lib/httparty.rb:560:in `perform_request'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/httparty-0.14.0/lib/httparty.rb:486:in `get'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:65:in `get'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:40:in `block (2 levels) in paged_request'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:39:in `loop'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:39:in `block in paged_request'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `each'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `each'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `find'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `pull'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket.rb:54:in `pull_id'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:4:in `pull_comments'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/formatter/pull_request_formatter.rb:6:in `existing_comments'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/formatter/git_formatter.rb:6:in `format'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto.rb:67:in `block in run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto.rb:66:in `each'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto.rb:66:in `run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/cli.rb:61:in `block in run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/cli.rb:60:in `chdir'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/cli.rb:60:in `run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor.rb:369:in `dispatch'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/bin/pronto:6:in `<top (required)>'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/bin/pronto:23:in `load'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/bin/pronto:23:in `<main>'

Let me know if you need more info. I've set the .pronto.yml to:
all:
  exclude:
    - 'spec/**/*'
# exclude files for single runner
eslint:
  exclude:
    - 'app/assets/**/*'
bitbucket:
  slug: repo/site
  username: user
  password: pass
  web_endpoint: http://stash.localhost:7990
max_warnings: 150
verbose: false

Upon further investigation, it looks like it is hitting Bitbucket via HTML instead of JSON as well. I tried hard-coding our URI by adding base_uri 'http://stash.localhost:7990/' to pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb but now it explodes because
  def get(url, query)
    self.class.get(url, query).parsed_response
  end

gets an HTML page instead of a JSON response - prompting it to error with:
pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:48:in `block (2 levels) in paged_request': undefined method `each' for "values":String (NoMethodError)
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:44:in `loop'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/clients/bitbucket_server_client.rb:44:in `block in paged_request'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `each'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `each'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `find'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:27:in `pull'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket.rb:54:in `pull_id'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/bitbucket_server.rb:4:in `pull_comments'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/formatter/pull_request_formatter.rb:6:in `existing_comments'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/formatter/git_formatter.rb:6:in `format'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto.rb:67:in `block in run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto.rb:66:in `each'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto.rb:66:in `run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/cli.rb:61:in `block in run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/cli.rb:60:in `chdir'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/lib/pronto/cli.rb:60:in `run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor.rb:369:in `dispatch'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pronto-0.9.3/bin/pronto:6:in `<top (required)>'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/bin/pronto:23:in `load'
	from /Users/eumirgaspar/.rbenv/versions/2.3.1/bin/pronto:23:in `<main>'

pretty sure I just might be missing something here...

Hi @corroded,
I don't have experience about Pronto with BitBucket, but it seems like BitbucketServerClient instance should be initialized with API URL.
Your http://stash.localhost:7990 is most likely BitBucket itself not API.
Have you tried to specify api_endpoint for BitBucket in configuration file?

Looks like we have been in an older version of BitBucket (v4) so no API integration yet. Closing this now.


[ome] Add an option sil-dump-before-ome-to-path to dump the current m…

…odule to a path before stripping ownership.
This will simplify analyzing SIL as we move the ownership model eliminator back
through the pipeline.

@swift-ci smoke test and merge


Implement RFC 0053: Create Static Jammy Buildpackless Builder

In https://github.com/paketo-buildpacks/rfcs/blob/main/text/0053-add-static-stack.md, the creation of a new static stack, and related buildpackless builder were introduced.
Since then, the Jammy static stack has been created: https://github.com/paketo-buildpacks/jammy-static-stack. In order to make this a more useable addition, we should implement the buildpackless static builder as described in the RFC.
Per the RFC:

The builders team will create a new Github repository at: paketo-buildpacks/builder-jammy-buildpackless-static similar to existing buildpackless builders.

cc @paketo-buildpacks/builders-maintainers

@sophiewigmore i think we were holding off on creating a buildpackless builder until we validated that the stack was usable by any of our supported buildpack.
I started exploring integration with Go (see this slack thread) but I ran into some Go-specific issues and deprioritized the investigation. I didn't try Rust, which is the other language I'd expect to work on the scratch stack. I'm not 100% sure if Java Native would work on static or not - I'm not familiar enough with that ecosystem.
If we don't ever get to the point of integrating the static stack with Paketo Buildpacks, even a buildpackless-builder seems like a bit of overkill.
Was there something specific you were looking to achieve with a buildpackless builder, or were you just trying to ensure the RFC was fully implemented?

@robdimsdale I didn't see that thread, that makes sense though. The goal of this issue was to make sure the RFC gets fully implemented. Whether the resolution is to re-explore this or to opt not to go through with a builder, it'll be good to have an easily-discoverable record of that decision.

This is an example of where a static builder would be useful: https://github.com/paketo-community/rust/issues/288

Give the above use-case of a community member trying to build a statically-linked self-contained rust app, and given the relatively low-cost of maintaining this builder, I think it's worth prioritizing the creation (and ongoing maintenance) of this builder.

Repo created at: https://github.com/paketo-buildpacks/builder-jammy-buildpackless-static

Automation is hooked up and the first release of the builder has been created: https://github.com/paketo-buildpacks/builder-jammy-buildpackless-static/releases/v0.0.1. I'll close this issue now as the builder is usable via paketobuildpacks/builder-jammy-buildpackless-static.


Improve testing structure

We need to move into one single cargo project.

:link: zboto Link

In this issue we should include https://github.com/Zondax/filecoin-solidity/issues/119


Where can i find pretrained Imagenet model?

I want to train my model with checkpoint the aforementioned model. Anyone know where should i download it from?  @arslan-chaudhry  @DrSleep
When i try to load resnet_101_v2  pretrained model  i get  the following error:
NotFoundError (see above for traceback): Restoring from checkpoint failed. This is most likely due to a Variable name or other graph key that is missing from the checkpoint. Please ensure that you have not altered the graph expected based on the checkpoint. Original error:
Tensor name "bn2a_branch1/beta" not found in checkpoint files ./snapshots2/resnet_v2_101.ckpt
[[Node: save_1/RestoreV2 = RestoreV2[dtypes=[DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT, ..., DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT, DT_FLOAT], _device="/job:localhost/replica:0/task:0/device:CPU:0"](_arg_save_1/Const_0_0, save_1/RestoreV2/tensor_names, save_1/RestoreV2/shape_and_slices)]]
 [Node: save_1/RestoreV2/_225 = _Recv[client_terminated=false, recv_device="/job:localhost/replica:0/task:0/device:GPU:0", send_device="/job:localhost/replica:0/task:0/device:CPU:0", send_device_incarnation=1, tensor_name="edge_230_save_1/RestoreV2", tensor_type=DT_FLOAT, _device="/job:localhost/replica:0/task:0/device:GPU:0"]()]

you can try to convert caffe to tf as described here: https://github.com/DrSleep/tensorflow-deeplab-resnet#caffe-to-tensorflow-conversion


Changed api.Variable to have a machine readable value

Implements #243, Workaround for #186, #106, #83
I have moved conversions.go from api to proc, this way I could import service/api into proc and use the type SimpleType defined there in proc, without having to duplicate it.
api.Variable now has two methods to convert it into a string: SinglelineString and MultilineString.
SinglelineString is mostly identical to the previous serialization, the two differences are that I'm quoting string values and when variables are cut from the evaluation because we reached the recursion limit instead of printing {...} I print (*<type>)(<address>) which could be (in the future) be used by a user to further explore the data structure.
MultilineString is a simple attempt at pretty printing, I'm sure it can be improved significantly.
I have also included a workaround for Issue #186 (and related issues). When there is more than one definition of a variable in scope I'll return a Variable with SimpleType multi and the list of its possible values as Children. Those issues should still get their compiler side fix but in it's not going to happen soon and it's unlikely that it will ever happen for 1.4.x and 1.5.0/1.5.1.
There will probably be conflicts with #261, I will fix them when that's merged.

I'd rather keep proc in the dark about the API. What about defining SimpleType in proc instead, and importing it into api? The api conversions could, in the future, be tied to a certain version of the api we expose (which we really should consider that we're building v1 of the api and namespace it as such now).
Fixes for #186, #106, #83 should be landing in Go 1.6, at least that's what I've been told.
Can you separate the workaround code for #186, #106, #83 into a different PR (on top of this one), but keep the new serialization code in this PR (quoted strings, SingleLine, MultiLine).

I'd rather keep proc in the dark about the API. What about defining SimpleType in proc instead, and importing it into api?

Done, however I also had to bring prettyprint.go over to proc, the tests in variables_test.go need a way to do serialize proc.Variable.

Can you separate the workaround code for #186, #106, #83 into a different PR

Done, I have restored the previous behaviour, with EvalVariable returning the first variable with a given name, however I would suggest returning an error instead if we aren't doing the workaround.

Fixes for #186, #106, #83 should be landing in Go 1.6, at least that's what I've been told.

That would be great news, I checked the issue tracker but found nothing (except for old bugs)

This change looks great, I am looking forward to more readable print output for complex objects.
I have a few comment/suggestion about the change:

Does MultilineString and pretty printing need to be in the server? If a client (e.g. terminal) has a JSON-based representation of a variable it can do pretty printing itself and even apply custom formatting rules without any remote calls
It would be good to add maxVariableRecurse and maxArrayValues parameters to the EvalVariable API call instead of hard-coding them

Does MultilineString and pretty printing need to be in the server?

MultilineString runs in the client.

MultilineString runs in the client.

I am not yet very familiar with the code and its usages but I would have expected MultilineString to be in terminal package then (not exported). Unless delve also aims to provide a library that can be used to write another client app in Go.

@aarzilli I agree with what @kostya-sh is saying. The prettyprint logic should be in terminal/ or api/types. I think I'd prefer terminal/ since api/types should remain relatively generic. I think the api.Variable type that the client receives should have all of the necessary information for the terminal client to pretty print.

So, do you want to move variables_test.go to service/test? Those tests depend on the serialization code (and, in general, using serialization is a convenient way to test these things).

@aarzilli no, we shouldn't have to move all of variables_test.go to service/test, only the specific bits that deal with the stringifying of the data structure, unless I'm missing something. I think it is totally appropriate to test the raw memory -> Variable structure at the proc level, but anything that is purely concerned with output (pretty printing) should be moved elsewhere.

Every test in variables_test.go uses stringification to do its job, doing it without stringification seems pretty inconvenient. For example this test case:
{"a12", "[]main.FooBar len: 2, cap: 2, [{Baz: 4, Bur: \"d\"},{Baz: 5, Bur: \"e\"}]", "", "struct []main.FooBar", nil},

would become something like this:
{"a12", Variable{ Len: 2, Cap: 2, Children: []Variable{ { Children: []Variable{ { Name: "Baz", value: 4 }, { Name: "Bur", value: "d" } } }, { Children: []Variable{ { Name: "Baz", value: 5 }, { Name: "Bur", value: "e" } } } } }, "", "struct []main.FooBar", nil }

a13 in TestVariableEvaluation is even worse because of all the pointers involved.

@aarzilli right, that is inconvenient. What if we kept some basic tests in proc to assert about simple evals and small things like your patch to include []Children and then move the rest of the tests over to service/test and test it at the post-serialization level?

Done.

scope.extractVarInfoFromEntry is not the only thing that makes variables, toField, maybeDereference and loadArrayValues also do. Those do not have entries.

@aarzilli good point. A few ideas:

Add method to scope to look up entry for a given name.
Fill out the GoType for all []Children at the highest level
Store the dwarf.Entry on Variable, that way we can use Entry.Offset to seek the reader and parse the children entries for structs, etc..

Thoughts?

I've started doing this change but tbh I'm not liking it. Tracking both dwarf.Type and the type entry is verbose and redundant. Tracking only the type entry wouldn't be redundant but far more verbose. What's the objection to using golang.org/x/debug/dwarf that keeps track of AttrGoKind in dwarf.CommonType?

So, CommonType has ReflectKind and Offset, so that should be all we need (likely just ReflectKind). Ideally we replace the SimpleType stuff with a switch on ReflectKind if we can, so we don't have to define all of those types ourselves and just rely on the actual information given in the Dwarf info. Does that make sense or did I miss your point? If so ping me on gitter and we can talk through it.

All correct, however only CommonType from golang.org/x/debug/dwarf has ReflectKind, the one from debug/dwarf in go's standard library doesn't (yet?).
If we switch we can remove SimpleType from Variable (and all the St* constants) and just use Variable.RealType.ReflectKind.

@aarzilli you're right, that's annoying. I'd much rather rely on the stdlib package, as that is more likely to be actively maintained for the time being. My current thought is, lets vendor debug/dwarf with the patch applied to have offset and reflectkind on commontype, and then submit a patch to get it merged in upstream before the 1.6 code freeze.
Thoughts?

Thoughts?

Actually, we can't do this one either. The code in golang.com/x/debug/dwarf discards the value of ReflectKind in some circumstances (strings and slices at least) so we can't use it.

@aarzilli alright, go ahead and change SimpleType to reflect.Kind and let's leave it at that for now.

Done

Are we ok to ignore the Unreadable error here?

If I didn't miss anything it should be.

Should we return it as an error instead of cloning?

IMHO errors should be for actual errors: either we can't make sense of the debug information or there is an error in the user supplied expression. Being unable to read memory isn't an error, it just means we are dealing with uninitialized or corrupted memory, it should be normal for a debugger.

@aarzilli it looks like there is still code in this PR for handling poor scoping info, etc.. that should have been removed when submitting #270, i.e. the various extractVar* methods returning a slice instead of the var itself.

it looks like there is still code in this PR for handling poor scoping info

removed

@ironcladlou would like your input here as well with regard to the work you've done on #278.

Still catching up, but in general this approach while more complex for clients seems to be way closer to the end-game than #278 (which is easy to render but lacks all the type information).
One thought regarding https://github.com/derekparker/delve/pull/268#issuecomment-147798767: The example justifying testing against rendered output could perhaps be simplified with test-scoped functions and types to build Variables from more compact commands/structs. I think it's important to have strong tests against the internal types; relying on a particular rendering of the variables for this particular class of test is only going to make it even harder to change the internal types in the future (something we're already getting a taste of.)
Getting variable access solvent for clients is extremely important for any useful tool integration, so I'm wary of pulling the tests up away from proc.

Quick clarification:

Getting variable access solvent for clients is extremely important for any useful tool integration, so I'm wary of pulling the tests up away from proc.

I see that the tests are still in proc but rely on rendered output, so the overall point still stands.

Still catching up, but in general this approach while more complex for clients seems to be way closer to the end-game than #278 (which is easy to render but lacks all the type information).

Can you expand on that a bit? What in particular is more complex for clients and do you have any thoughts on what could be simplified?

I see that the tests are still in proc but rely on rendered output, so the overall point still stands.

That's true, however I think possibly a mixed approach could be useful here. We certainly need to assert on rendered output, however maybe that's best kept in service/test and anything that asserts about the actual underlying data structure that Delve uses (i.e. Variable) could be left in proc. The latter being type information, value, kind, etc. That would complicate the proc tests but I think it makes sense as far as separation of concerns goes.

Still catching up, but in general this approach while more complex for clients seems to be way closer to the end-game than #278 (which is easy to render but lacks all the type information).

Can you expand on that a bit? What in particular is more complex for clients and do you have any thoughts on what could be simplified?

Just that with the approach in #278, the client can basically print the raw JSON and get something instantly human readable (which was important to me while developing debugger infrastructure from scratch in Sublime), like:
Locals:
fde1 (*struct github.com/derekparker/delve/dwarf/frame.FrameDescriptionEntry): {
  "Instructions": [],
  "CIE": null,
  "end": "49",
  "begin": "0",
  "Length": "0"
}
foo (struct string): "testing!"

That's enough to be useful for me right now, but probably not enough for a more advanced IDE integration. My needs are likely simpler than those of the IntelliJ plugin or LiteIDE which have the ability to do things like render interactive tree views and stuff for drilling down (with Sublime I'm basically working with a static text view for my debugger output, so I'm trying to show only what's absolutely necessary at the moment.)
With the data structures in this PR, I'll have to write a renderer that can walk the children and print stuff according to type, etc, just like the one included here. Which was inevitable anyway. I can't really think of a simpler way to represent the data than you guys have come up with. I don't think it's imposing an unreasonable burden on the client or anything.

I see that the tests are still in proc but rely on rendered output, so the overall point still stands.

That's true, however I think possibly a mixed approach could be useful here. We certainly need to assert on rendered output, however maybe that's best kept in service/test and anything that asserts about the actual underlying data structure that Delve uses (i.e. Variable) could be left in proc. The latter being type information, value, kind, etc. That would complicate the proc tests but I think it makes sense as far as separation of concerns goes.

Agree; I didn't mean to say there's no use in testing the renderers. Just that I think renderer tests are separate from the Variable tests (and that the latter should be tested directly against Variables, not against rendered output, and that there are strategies for making that less annoying).

I started writing some code for the expression evaluator and realized that it's much easier if Variable.Value is a go/constant.Value instead of interface{}, I've added a commit to change this.

I've been really busy the past several days, however I'm going to finish reviewing this tonight, from what I remember the code LGTM but I'll go through everything tonight and put in the final review if anything needs to be changed and get this merged in asap.

Regarding documentation on proc.Variable's fields, I documented them in api.Variable, is it enough to copy those comments over?

merged


Add gh action ci

Codecov Report

Merging #18 into master will not change coverage by %.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #18   +/-   ##
=========================================
  Coverage     79.68%   79.68%
  Complexity       76       76
=========================================
  Files            13       13
  Lines           192      192
  Branches          9        9
=========================================
  Hits            153      153
  Misses           37       37
  Partials          2        2

Continue to review full report at Codecov.

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


Get consistency across use of isRequired on props

A lot were removed during development that should be put back in for the production version

Brought this forward to v0.5.1 in order to fix a defect.


error

[ERROR] The distro "kali-linux" has running processes and can't be operated. "wsl -t " or "wsl --shutdown" might help.

在服务中  手动终止 Hyper-V  就可以了


Flow of execution

This is an informational PR.
It handles unhappy paths first, then the happy path.

source

The current design of if-s are human.

@betterthanclay Oh no! It was meant to show the flow of execution.

Yeah - makes sense to include the change, it's a valid improvement to the code 👍


New PR to test SignCLA at 2018-08-22 00:56:09.13727378 +0000 UTC m=+4.970469735

Body of PR

corp-pass-staging: test succeeded


v1.3 backports 2019-02-10, part 1

PRs:

#6992
#6978
#6953

Both #6970 and #6809 require custom implementations due to complex conflicts, proposal will come in part 2.

This change is

test-me-please

test-me-please

test-me-please

test-me-please

Build failure: https://jenkins.cilium.io/job/Cilium-PR-Ginkgo-Tests-Validated/9773/flowGraphTable/
All test suites timed out (indicating either a regression, or some possible load / environment issue on the baremetal machines on which the CI runs).

test-me-please

test-missed-k8s

test-docs-please


Wrong docs on move cursor to preview/list

Code in guihua.lua:
https://github.com/ray-x/guihua.lua/blob/a6e6655b60f303dffc85fa70da02a23963f9b3b8/lua/guihua/listviewctrl.lua#L89
https://github.com/ray-x/guihua.lua/blob/a6e6655b60f303dffc85fa70da02a23963f9b3b8/lua/guihua/textviewctrl.lua#L37
Key mappings are contrary to the docs in the readme.

My suggestion is to exchange the key mapping in guihua.lua

Thanks, you are right. Updated


GEODE-68: GFSH SYS_HOST_NAME variable should report hostname if avail…

Populate the SYS_HOST_NAME variable with the system host name if possible.  Otherwise, set it to localhost.

Resubmitting due to Travis failure.


[feature] support jaeger telemetry

Description
Logs are difficult to track complex logic, e.g. connection management.
This PR uses Jaeger to provides a basic debugging environment.
Add flag:

jaeger  enable the jaeger telemetry
jaeger-address  jaeger thrift protocol endpoint

Changes include

[x] New feature (non-breaking change that adds functionality)

Checklist

[x] I have assigned this PR to myself
[x] I have added at least 1 reviewer
[x] I have added the relevant labels

Testing

[x] I have tested this code with the official test suite
[x] I have tested this code manually

Manual tests

Install local jaeger server docs
Run dogechain node, but add jaeger flag --jaeger --jaeger-address "http://<IP_ADDRESS>:14268/api/traces"
example: dogechain server --chain ./genesis.json --jaeger --jaeger-address "http://<IP_ADDRESS>:14268/api/traces"

Codecov Report

Merging #317 (156c6df) into dev (d7c5a9e) will decrease coverage by 0.22%.
The diff coverage is 62.89%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@            Coverage Diff             @@
##              dev     #317      +/-   ##
==========================================
- Coverage   47.74%   47.53%   -0.22%
==========================================
  Files         132      135       +3
  Lines       20125    20450     +325
==========================================
+ Hits         9608     9720     +112
- Misses       9684     9894     +210
- Partials      833      836       +3

Impacted Files
Coverage Δ

jsonrpc/jsonrpc.go
25.00% <ø> (ø)

network/discovery/discovery.go
26.53% <0.00%> (-1.22%)
:arrow_down:

network/identity/identity.go
21.60% <0.00%> (-3.95%)
:arrow_down:

helper/common/common.go
8.72% <46.42%> (ø)

network/peer_connect.go
72.50% <72.50%> (ø)

network/keep_available.go
69.86% <81.81%> (+1.05%)
:arrow_up:

network/server.go
71.78% <81.81%> (-0.20%)
:arrow_down:

network/e2e_testing.go
66.66% <100.00%> (+0.22%)
:arrow_up:

network/server_discovery.go
74.64% <100.00%> (+1.45%)
:arrow_up:

network/server_identity.go
91.39% <100.00%> (+0.70%)
:arrow_up:

... and 8 more

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


UnicodeEncodeError: 'ascii' codec can't encode character in Python3

I have seen a closed issue about this problem before. As suggested I switched to python3 but the problem still persists.
Here is the output log
python generate_line_box.py -i "data/train/alexis_ruhe01_1852_0018_022.tif" -t "data/train/alexis_ruhe01_1852_0018_022.gt.txt" > "data/train/alexis_ruhe01_1852_0018_022.box"
Traceback (most recent call last):
  File "generate_line_box.py", line 40, in <module>
    print(u"%s %d %d %d %d 0" % (prev_char, 0, 0, width, height))
UnicodeEncodeError: 'ascii' codec can't encode character u'\u017f' in position 0: ordinal not in range(128)
Makefile:110: recipe for target 'data/train/alexis_ruhe01_1852_0018_022.box' failed
make: *** [data/train/alexis_ruhe01_1852_0018_022.box] Error 1

The issue was https://github.com/OCR-D/ocrd-train/issues/18.
My guess is this happens because Python falls back to ascii for terminal output if it cannot determine the terminal to be UTF-8 capable.
Try export PYTHONIOENCODING=utf8 in your shell before you execute the script/makefile, Python should pick it up and not try to encode unicode characters to ascii.

That fixed it! Thanks a lot

thank youu


[SPARK-50579][SQL] Fix truncatedString

What changes were proposed in this pull request?
In the PR, I propose to respect the maxFields argument of SparkStringUtils.truncatedString in all cases independently from the size of the another argument seq. If size of seq is grater or equal to maxFields, output exact maxFields elements of seq.
Also, if the number of printed elements is zero, don't print the redundant comma , like [, ... 100 more fields], and don't overflow when maxFields is Int.MinValue.
Why are the changes needed?
To make output consistent for the same maxFields. For example, if maxFields is 2:
truncatedString(Seq(1, 2), "[", ", ", "]", maxFields = 2) -> "[1, 2]"

but for more elements in the input sequence, it prints only one element:
truncatedString(Seq(1, 2, 3), "[", ", ", "]", maxFields = 2) -> "[1, ... 2 more fields]"

though the expected output is "[1, 2, ... 1 more fields]".
Does this PR introduce any user-facing change?
No.
How was this patch tested?
By existing tests from UtilSuite that are moved to StringUtilsSuite and additional checks:
$ build/sbt "test:testOnly *StringUtilsSuite"

Was this patch authored or co-authored using generative AI tooling?
No.

Merged to master.


Task Disappears once I refresh the issue

When I run the build it's working. Once again if I refresh the page and check the task appears and undo button is enabled and if I click it the task is restored. Can you please me to sort this issue..

Could you describe more in detail what you're trying to do, what the actual result is and what the expected result is? If possible together with screenshots?

I will give you step by step process

Downloaded VSTS.Extension.SqlReportingServices and installed in TFS server which has a version of TFS2015.Update4.
2.I am sure it's installed as I can see the tasks of SSRS in my build steps.
3.Now I have added "Deploy SQL Server reporting files" task .
4.I have passed all required parameters to the task and saved it.
5.I have run the build and it's successful.
6.After that if I come back again to my build definition the task disappears. It happens only with the additional extensions not with build-in tasks.
The below image I am adding the task in my TFS

In the below image I am refreshing my browser , the task goes off but the undo button is enabled

Once I click the undo button the task is restored.
Something weird.......Please look into this

We haven't heard about this behavior before, but could you try uninstalling the extension completely and doing a fresh install?
There's nothing exotic about the task, it's a JSON file based on VSTS documentation and a PowerShell script. It's been in use for quite some time by many users.
So perhaps something went wrong during the installation or perhaps there were issues on VSTS/Azure at the time.

The extension is only tested on VSTS (TFS on Azure) though.
(Although some users have used it on premise as well.)

I can only confirm what my collegue said: the task is mainly targetting VSTS (partly tfs 2017). We've not tested it in 2015 and are not maintaining it for TFS 2015.


Update reactivemongo-bson-api to 1.0.1

Updates org.reactivemongo:reactivemongo-bson-api from 1.0.0 to 1.0.1.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.reactivemongo", artifactId = "reactivemongo-bson-api" } ]

labels: library-update, semver-patch

Superseded by #159.

Superseded by #159.


'Next' & 'Cancel' are not localized on Connect to Cosmos DB dialog

Storage Explorer Version: 1.10.1
Build: 20190926.4
Branch: master
Platform/OS: Windows 10/ Linux Ubuntu 18.04/macOS High Sierra
Architecture: ia32/x64
Language: Chinese (zh-TW) / Chinese (zh-CN)
Regression From: Not a regression
Steps to reproduce:

Launch Storage Explorer using the command 'StorageExplorer.exe --lang=zh-CN'.
Right click 'Cosmos DB Accounts (Preview)' -> Select 'Connect to Cosmos DB'.
Check the prompt dialog.

Expect Experience:
'Next' & 'Cancel' are localized.
Actual Experience:
'Next' & 'Cancel' are not localized.

Please confirm, are these buttons exposed to localization ?

They are, but the dialog panels here aren't setting the button text. They're just using the default, hard-coded text.

Azure Storage Explorer support for Azure Cosmos DB has been discontinued as of v1.24.0. We recommend users to use Azure Cosmos DB’s Data Explorer, which can be found in Azure Portal or as a stand-alone version in http://cosmos.azure.com/ for the best Azure Cosmos DB experience. You can also find additional Azure Cosmos DB tooling here: Azure Cosmos DB Tools


STOR-1570: Chore: Update secrets-store-csi-driver to the latest release

https://issues.redhat.com/browse/STOR-1570
This rebases the driver on the v1.4.0 upstream release, bringing in the following changes since v1.3.4

test: more usage of t.TempDir()
chore: bump github/codeql-action from 2.3.0 to 2.3.2
chore: bump codecov/codecov-action from 3.1.2 to 3.1.3
ci: [StepSecurity] Apply security best practices
chore: bump golang from 403f486 to 79ffe35 in /test/e2eprovider
chore: bump monis.app/mlog from 0.0.2 to 0.0.4 in /test/e2eprovider
docs: add openssf badge
chore: bump golang from 403f486 to 79ffe35 in /docker
chore: bump k8s.io/klog/v2 from 2.80.1 to 2.100.1 in /test/e2eprovider
chore: bump google.golang.org/grpc in /test/e2eprovider
chore: update node-driver-registrar:v2.8.0, livenessprobe:v2.10.0
chore: bump step-security/harden-runner from 2.3.1 to 2.4.0
chore: bump github/codeql-action from 2.3.2 to 2.3.3
chore: bump golang from eaf1267 to 31a8f92 in /docker
chore: bump golang from 79ffe35 to 31a8f92 in /test/e2eprovider
Use dl.k8s.io instead of hardcoded GCS URIs
chore: bump actions/setup-go from 4.0.0 to 4.0.1
chore: bump codecov/codecov-action from 3.1.3 to 3.1.4
chore: bump k8s deps to v1.26.4 (#1254)
fix: make manifest diff
test: improve nodeserver testing
chore: bump k8s.io/code-generator from 0.26.4 to 0.27.2 in /hack/tools
Update concepts.md
chore: bump github.com/golangci/golangci-lint in /hack/tools
chore: bump github/codeql-action from 2.3.3 to 2.3.6
release: update manifest and helm charts for v1.3.4
chore: bump goreleaser/goreleaser-action from 4.2.0 to 4.3.0
chore: bump actions/checkout from 3.5.2 to 3.5.3
chore: bump actions/dependency-review-action from 3.0.4 to 3.0.6
chore: bump github/codeql-action from 2.3.6 to 2.20.0
Enable image digest as pulling option
chore: bump github.com/golangci/golangci-lint in /hack/tools
chore: bump k8s.io/code-generator from 0.27.2 to 0.27.3 in /hack/tools
chore: bump sigs.k8s.io/controller-tools in /hack/tools
chore: bump ossf/scorecard-action from 2.1.3 to 2.2.0
chore: bump github/codeql-action from 2.20.0 to 2.20.1
chore: update debian-base to bookworm-v1.0.0
chore: bump github/codeql-action from 2.20.1 to 2.20.3
chore: bump github/codeql-action from 2.20.3 to 2.20.4
chore: bump sigs.k8s.io/controller-tools in /hack/tools
docs: mention sig-auth subproject in readme
AWS provider has a Helm chart
chore: bump github/codeql-action from 2.20.4 to 2.21.0
chore: bump k8s.io/code-generator from 0.27.3 to 0.27.4 in /hack/tools
chore: bump github/codeql-action from 2.21.0 to 2.21.2
chore: cleanup secretproviderclass status
helm: aggregated clusterrole to view secretproviderclasspodstatuses
chore: bump github/codeql-action from 2.21.2 to 2.21.5
chore: bump actions/checkout from 3.5.3 to 4.0.0
chore: bump golang.org/x/net from 0.8.0 to 0.17.0 in /test/e2eprovider
chore: bump golang.org/x/net from 0.8.0 to 0.17.0
chore: bump golang.org/x/net from 0.10.0 to 0.17.0 in /hack/tools
Remove driver name hardcode
chore: bump google.golang.org/grpc in /test/e2eprovider
chore: bump google.golang.org/grpc from 1.49.0 to 1.56.3
chore: update to go 1.21
chore: update to go 1.21.4 in docker
chore: bump version to v1.4.0 in release-1.4
release: update manifest and helm charts for v1.4.0

Diff to upstream v1.4.0:
https://github.com/kubernetes-sigs/secrets-store-csi-driver/compare/v1.4.0...dobsonj:rebase-v1.4.0
/cc @openshift/storage

/lgtm

Adding the label based on Regression test results added here: https://issues.redhat.com/browse/STOR-1570
/label qe-approved

/label docs-approved
/label px-approved


How to start in production

Is there an example of starting the queue in a production server?

node ace queue:start
How to keep it running is up to you and your operating system. You can use pm2, screen, tmux, systemd, Start-process, Invoke-Command to mention some

Hey how's it going?
How do I create parallel queues?
example: I have 8 processes for sending emails (using pm2) and I want to have 1 process checking the returns (aws SAS).
I want one village not to wait for the other.

I thought it was..
queues: {
database: {
driver: 'database',
tableName: 'adonis_jobs',
pollingDelay: 500,
},
feedback: {
driver: 'database',
tableName: 'feedback_jobs',
pollingDelay: 1000,
}
},
node ace queue:start feedback

how to associate classJob ex:
export default class EmailFeedback extends BaseJob {}
how to associate the classJob with the feedback queue?

How do I create parallel queues?

You can start it multiple times with npm run queue:start or npm run queue:start queueName

how to associate the classJob with the feedback queue?

You can't assign class in class declaration, but you can decide to which queue to add it with useQueue(queueName) when dispatching jobs
EmailFeedback.useQueue('feedback').dispatch()

Closing issue, since it's not related to running in prod, which got resolved


App data persists between invocations.

Need to make the app stateless; new request needs to clear existing data.

Added new scenario test, fixed code in commit 25d24623cf91e624d9773349c9950344db740996.
Deployed to Heroku


Add the beginnings of the leaderboard

Populate w/ entries from the paper.

Doubt we are doing this since PyGaggle is turning out to be a general ranking/qa framework, closing for now.


Add --allow-env flag to relevant hooks

Summary
Implement App manifest override proposal with environment variables

Proposal: https://corp.quip.com/O1t1AuDG3HLk/App-Manifest-Overrides
JIRA: https://jira.tinyspeck.com/browse/HERMES-4137

Related CLI PR:

https://github.com/slackapi/slack-cli/pull/776
Related runtime PR:
https://github.com/slackapi/deno-slack-runtime/pull/40

Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Stale socket can prevent plugin from starting

We've been working on implementing vault-kubernets-kms into a bare-metal cluster, and it happens that one of the control-plane node has a hardware fault, and is restarting frequently.
On this node, we observed that when the plugins starts after a previously unexpected shutdown, crashes with an error about the socket already being in-use (/opt/kms/vaultkms.socket, in the default configuration)
Would it be possible to pass an argument to the plugin to overwrite a stale socket, rather than crash? In the current setup, it's possible that (for example) a power failure will take all the controlplane nodes down suddenly, and then the apiservers won't be able to restart on power restore, because the vault-kubernetes-kms isn't available due to the existing socket file :(
Thanks!
D

vault-kubernetes-kms v0.3.0 ships with a -force-socket-overwrite (FORCE_SOCKET_OVERWRITE); default: false flag  :)


feat(autoware_map_based_prediction): add backlash within lanelet

Description
Add backlash within lanelet when predict paths.
Background: Small bikes are tend to drive side within the lane. However, the predictor yields the paths always to the center of the lane.
Related links
Parent Issue:

Link

How was this PR tested?
TIER IV Cloud

planning scenario

Notes for reviewers
None.
Interface changes
None.

Effects on system behavior
None.

Current processing time:

replace it by https://github.com/autowarefoundation/autoware.universe/pull/8602


Segment Anything for Microscopy

Hi Dylan. Thanks for this great initiative to assimilate all the works from the community towards Segment Anything applications.
I would be willing to add our contribution to the community - Segment Anything for Microscopy.
(I have added the respective components to this PR to our project - let me know if there's anything expected from our side, thanks)

@anwai98 Thank you for your great work. I  have merged.


key: AlwaysUseMSOAuthForAutodiscover reg key required

Why isn't this key listed? It appears to be required for Outlook 2016 to transition to use modern auth. I enabled modern auth (OAUTH) for Windows Outlook and NO USERS are being prompted to use modern auth. I even set up a brand new machine and it failed also. This doesn't seem to work without that key also but it is absent from this page. All these registry keys are pretty lame considering Microsoft makes both Office365 and Outlook 2016. You couldn't have made this easier for clients??
Also Outlook "365" actually is Outlook 2016? The branding further complicates this issue.
Outlook 2016
Modern Authentication is enabled by default.

Recommend that users force Outlook to use Modern Authentication. To do that, set the DWORD value of the following registry key to 1.

HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover

For more information, see KB 3126599 - Outlook prompts for password when Modern Authentication is enabled.

MAPI/HTTP cannot be disabled. For more information, see KB 2937684 - Outlook 2010, 2013, or 2016 may not connect using MAPI over HTTPs as expected.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 059ed9a7-ea75-0fa3-e246-4ad1f1b0c5bc
Version Independent ID: d7598f96-3158-09ee-024a-6175599718cd
Content: How modern authentication works for Office 2013 and Office 2016 client apps
Content Source: Enterprise/modern-auth-for-office-2013-and-2016.md
Service: o365-administration
GitHub Login: @MSFTTracyP
Microsoft Alias: tracyp

@afield1235  - Thank you for submitting feedback.
I will get this issue over to the Enterprise writing team for investigation.
Thank you for reporting and making the docs better. Much appreciated.
I made a note to request the team to update this when the work is complete.

Added on PR #603

Article is updated. My thanks, all!

@afield1235 -  From our understanding, the issue has been resolved so we will close this issue.
Thank you for your contribution to make the docs better! Much appreciated!


Test Pipeline doesn't send both reports

Ansh broke the PRs

Fixed, codecov was just referencing master branch but we had since changed it to main

Fixed, codecov was just referencing master branch but we had since changed it to main


Implement direct usize indexing

where
    IndexMap<K, V, S>: IndexMut<usize, Output = V>,
    IndexSet<T, S>: Index<usize, Output = T>,

This allows map[i] and set[i] indexing to access values directly,
panicking if the index is out of bounds, similar to slices.
On maps, this somewhat overlaps with Index<&Q> + IndexMut<&Q> where
Q: Equivalent<K>. The reference makes this indexing unambiguous, but
it could be confusing to users if the key type is also an integer.

In my experiments in rustc, replacing HashMap,Vec combinations with indexmap, I've found it annoying to replace direct vec[i] indexing with get_index(i).unwrap().1. I didn't find anywhere that we've considered Index<usize> before, but it would make this a lot easier.

One downside is that with my experiment of custom index types, I would ideally replace this Index<usize> with Index<Idx> for IndexMap<K, V, S, Idx>, but I can't prove that Index<Idx> and Index<&Q> are distinct. We could still allow Index<usize> with any Idx though.

I think we should just wait with this, in that case. If we have an indexing operator, IMO it must use the index type that we have parameterized the map with.

I brought this up in the forum: https://users.rust-lang.org/t/any-tricks-for-generic-overlap-with-references/45186
I now think the answer is that we shouldn't try to create generic Index<Idx> at all. Instead, we can just add concrete Index<usize> and Index<u32> for maps and sets of the corresponding index type. Then if a user has a newtype index, coherence will still let them write their own Index<MyIndex>, which just needs to call get_index and unwrap/expect.

That makes sense but

ith Index for IndexMap<K, V, S, Idx>, but I can't prove that Index and Index<&Q> are distinct

Won't we have a trait bound on Idx? If that's a local trait it should be enough, it will prove that no references implement it? (Or maybe that doesn't work because references are fundamental)

(Or maybe that doesn't work because references are fundamental)

I think that's it. I shared a simplified playground, if you want to experiment with it:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=161bde1feeaa8c4aaaa864636f2f2ae1
error[E0119]: conflicting implementations of trait `std::ops::Index<&_>` for type `Container<_, &_>`:
[...]
   = note: downstream crates may implement trait `AsIndex` for type `&_`

@bluss any more thoughts on this? My plan for custom index types is to just implement each manually, rather than trying to have a blanket impl that potentially conflicts with Index<&Q>.
impl<K, V, S> Index<usize> for IndexMap<K, V, S, usize> {...}
impl<K, V, S> Index<u32> for IndexMap<K, V, S, u32> {...}
// perhaps all unsigned integers
// users can do their own `Index<NewTypeIndex>`

Let's go ahead with that plan then...


CSS Chart

Recreated text chart with HTML and CSS

You can absolutely do that, and it'll probably be easier to get it responsive etc. But I did the ASCII version mostly to showcase ASCII drawing itself (it's a pretty crazy example, to be honest, probably not something anyone should do.) And I want to keep the CSS light, so I'm closing the PR.


Why ParseCtx.compile doesn't return a Result?

The implementation of ParseCtx.compile(jaq_syn::Main) is currently error-prone because, if internally the compilation fails, the compile method returns a default Filter (i.e., .) and the public field ParseCtx.errs is populated with the errors. This design makes the usage of ParseCtx.compile() a bit error-prone as it's not obvious that the field errs must be checked. So, my question is, why not return a Result<Filter, Vec<Error>> instead of Filter and get rid of the field errs in ParseCtx?
If the underlying reason is a concern for backward compatibility, then I suggest creating a second method safe_compile or checked_compile that returns a Result<Filter, Vec<Error>> and marking the compile method as deprecated.

I agree with you totally. I'm currently working on jaq 2.0, and I plan to return Results for functions like the one you mentioned. This will also cut down on other boilerplate as @Andrew15-5 suggested in #188.


Cascading Search Meaningful Error Messages

11/08/2024
Custom Python environment 3.12.5
Coincident version: '0.1.dev40+gfa66db4.d20241108'
cascading_search returns ValueError ValueError: ItemCollection is empty, cannot convert to GeoDataFrame when a one of the datasets in secondary_datasets doesn't return a 'hit'.
Returns TypeError unsupported operand type(s) for *: 'GeometryArray' and 'float' when the overlapping datasets in the search don't meet the min_overlap_area minimum. ie. when geographic_area() returns an empty gdf due to datasets not meeting minimum area constraint,  subset_by_minimum_area() raises the error

Thanks for digging into this @Jack-Hayes ! I'd say it's really 2 separate issues.

cascading_search returns ValueError ValueError: ItemCollection is empty, cannot convert to GeoDataFrame when a one of the datasets in secondary_datasets doesn't return a 'hit'.

Do you think it's better to just clarify the error message by including the dataset name without hits? Or warn instead and proceed to the next secondary dataset?

TypeError unsupported operand type(s) for *: 'GeometryArray' and 'float' when the overlapping datasets in the search don't meet the min_overlap_area minimum. ie. when geographic_area() returns an empty gdf due to datasets not meeting minimum area constraint, subset_by_minimum_area() raises the error

Agreed we want to avoid that confusing error. Would you prefer to just return the empty geodataframe or raise a more informative ValueError for this case?

For

cascading_search returns ValueError ValueError: ItemCollection is empty, cannot convert to GeoDataFrame when a one of the datasets in secondary_datasets doesn't return a 'hit'.

Do you think we could implement a warning message displaying the dataset name without hits as well as returning only the gdfs with hits? I think if I had to pick between the two I would rather  clarify the error message by including the dataset name without hits!
For

TypeError unsupported operand type(s) for *: 'GeometryArray' and 'float' when the overlapping datasets in the search don't meet the min_overlap_area minimum. ie. when geographic_area() returns an empty gdf due to datasets not meeting minimum area constraint, subset_by_minimum_area() raises the error

I think a more informative ValueError would be best!


botbuilder-ai does not pass qnaId to the custom question answering endpoint

Versions
What package version of the SDK are you using: 4.1.6
What nodejs version are you using: v14.17.3
What browser version are you using: N/A
What os are you using: N/A
Describe the bug
In the source code in botbuilder-ai, languageServiceUtils.ts, function queryKnowledgebaseRaw, the code does not pass properly queryOptions.qnaId to the custom question answering REST call. This gives a wrong behaviour, when using prompts in the knowledge base.
It is this source code part:
https://github.com/microsoft/botbuilder-js/blob/main/libraries/botbuilder-ai/src/qnamaker-utils/languageServiceUtils.ts#L88
There the code is missing the following within the JSON.stringify call:
qnaId: queryOptions.qnaId,

The "Test" functionality in the custom question answering is passing QnaId to the REST endpoint, so there the behaviour is correct, the bug applies only when running a custom bot with botbuilder-ai (e.g. using one of the samples).
To Reproduce
Steps to reproduce the behaviour:

Create a knowledge base with 3 questions, the idea is that the prompt will reference one question, but the text will be from a different one:

Qna ID: 1,  "question 1" - answer should contain prompt: "Question 2 explanation text", reference to Qna ID 2
Qna ID: 2, "question 2" - answer should be "question 2 answer"
Qna ID: 3, "Question 2 explanation text" - answer should be "question 2 wrong answer"

deploy the knowledge base and test with with local bot (not with the "Test" button in language studio, there it works correct), for example with sample
use the following question flow:

"question 1" - should give prompt with text "Question 2 explanation text"
Click on the prompt button

Expected behaviour
Correct behaviour would be to show "Question 2 answer", as we have direct reference to "question 2" using its ID. But in local bot (or bot deployed to Azure), it will give "question 2 wrong answer", because the framework is not passing Qna ID to the REST endpoint. Custom Question Answering service will then match the response just based on the text, which will result in Qna ID = 3.
Screenshots
N/A
Additional context
N/A

Thank you for the report. I will investigate.

@hlavacek,
When you say "reference to question 2", are you referring to the "Follow-up prompts" option in the CQA portal? I'm not quite sure what it is that you're doing.

yes correct, in the Language studio UI it is set up via "Add Follow-up prompts" button, if you export the bot as Excel, then this is stored in the column Prompts as JSON, with an ID reference to the target question.

I am able to reproduce this issue. The follow-up prompt is correctly triggered, but the answer to the second question is not returned, and instead the default "No answer found" message is given. I can also confirm that the C# version functions correctly.

Hi, I was able to repro this issue. Thanks for the clear steps. You are correct, qnaId was not being passed in payload body. I have created a PR  that will fix this issue. Thanks.


[MWPW-142523] Pricing Cards CTA

Describe your specific features or fixes
Allows the user to add a CTA of any link below pricing cards using only CSS and authoring. The CTA link must be outside the pricing-cards block and immediately below it.
Resolves: MWPW-142523
Test URLs:

Before: https://main--express--adobecom.hlx.page/express/
After: https://echen-compare-button--express--adobecom.hlx.page/express/

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 36.63%. Comparing base (97e2498) to head (b31f9e3).

Additional details and impacted files
@@            Coverage Diff             @@
##            stage     #738      +/-   ##
==========================================
- Coverage   36.72%   36.63%   -0.09%
==========================================
  Files         132      132
  Lines       25711    25711
==========================================
- Hits         9443     9420      -23
- Misses      16268    16291      +23

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

I have a feeling that they might complain the button looks small. Can you also quickly add the xlarge button style to it? Otherwise, this is all good!


[Open Source Project] Clean up RtpMediaPlayer library

I'm currently doing some work here since I'm adding some javadoc documentation in the code.

:+1:
On Fri, Feb 20, 2015 at 5:12 PM, ashyonline<EMAIL_ADDRESS>wrote:

I'm currently doing some work here since I'm adding some javadoc
documentation in the code.
—
Reply to this email directly or view it on GitHub
https://github.com/creativa77/AndroidStreamingClient/issues/29#issuecomment-75310796
.

--
-- Julian Cerruti

I think the cleaning was good enough :)


Folded card doesn't.show all entities

Describe the bug
If I use the folded option, some/many entities are not seen in the folded items, maybe because I have too many entities? The folded options is possibly limiting the numbers of items being collapsed (I see 21 folded items plus the 10 unfolded). It was easy to notice because when folded, it shows only one 100% entity, but I have many more items with 100%.
How to reproduce
Set to folded and compare the number of entities.
Expected behavior
Show all entities as shown when not folded.
YAML configuration
                            "card": {
                                "collapse": 10,
                                "color_thresholds": [
                                    {
                                        "color": "#de2d0d",
                                        "value": 25
                                    },
                                    {
                                        "color": "#f4b400",
                                        "value": 50
                                    },
                                    {
                                        "color": "#0da035",
                                        "value": 100
                                    }
                                ],
                                "name": "Battery level",
                                "show_header_toggle": false,
                                "sort_by_level": "asc",
                                "type": "custom:battery-state-card"
                            },
                            "filter": {
                                "exclude": [
                                    {
                                        "entity_id": "*battery*level*"
                                    },
                                    {
                                        "entity_id": "*protect_battery_health_state*"
                                    },
                                    {
                                        "entity_id": "sensor.battery_state"
                                    },
                                    {
                                        "domain": "device_tracker"
                                    },
                                    {
                                        "state": "unknown"
                                    }
                                ],
                                "include": [
                                    {
                                        "entity_id": "*battery*",
                                        "options": null
                                    }
                                ]
                            },
                            "type": "custom:auto-entities"
                        },

Version
Currently 1.2.0, but I have been using it possibly (almost) since you made it available in HACS (great work btw).

Do you see all entities when folded/collapsed view is turned off? I guess not.
Please add entities in battery card manually and let me know if it works. Currently is hard to tell if the problem is in auto-entities or battery card.

I do see all of them (~60) if I remove "collapse": 10
I will test adding manually as you said, but considering it shows up when I remove the collapse item, it doesn't look to be 100% auto-entities card, if any % is, because when I don't collapse, it shows up correctly, I guess the auto-entities provides the "found" entities and the battery card collapse them, but for any reason when it collapses, it shows up 31 entities (21 folded + 10 unfolded).

Ok if that's the case than it looks like the problem is here indeed. I'll take look

cool, thanks! my guess would be something like when it has folder config it is taking only up to the first 100%. it can be coincidence, but looks strange it stops exactly after the fist entity with 100%.

I have the problem that the collapsed (folded) entities don't show up in iphone iOS 13.2.2 when pressing the "arrow down".

@Zkaning the reason of your problem is a different thing. Please create a new issue for it

@fabricioavil I have found the reason of missing entities in your case, I think. Please try v1.2.1 and let me know if the issue is still there.

@maxwroc great! it is fixed!


Ashen rune effect text not added with handwraps of mighty blows

When using the ashen rune with handwraps of might blows you get the added damage but not the extra text that is correctly added when the rune is on a normal weapon.

I do notice that the note doesn't show when posting critical damage for handwraps or any weapon.