all: Go 1.16.13 release status

Issue tracking the go1.16.13 release by releasebot.

Log
2022/01/06 13:11:38 starting
2022/01/06 13:11:38 working in /usr/local/google/home/amedee/go-releasebot-work/go1.16.13
2022/01/06 13:11:38 $ git clone https://go.googlesource.com/go /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitmirror
2022/01/06 13:12:01 $ git config gc.auto 0
2022/01/06 13:12:01 $ git fetch origin release-branch.go1.16
2022/01/06 13:12:02 $ git clone --reference /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitmirror -b release-branch.go1.16 https://go.googlesource.com/go /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitwork
2022/01/06 13:12:03 $ git codereview change relwork
2022/01/06 13:12:03 $ git config gc.auto 0
2022/01/06 13:12:13 an associated security release branch "release-branch.go1.16-security" does not exist; assuming it has been merged and deleted, so proceeding as usual
2022/01/06 13:12:13 $ git rev-parse go1.16.13
2022/01/06 13:12:13 Release status issue title: "all: Go 1.16.13 release status"
2022/01/06 13:12:14 Release status issue: https://golang.org/issue/50476
2022/01/06 13:12:14 $ git add VERSION
2022/01/06 13:12:14 $ git commit -m go1.16.13

Change-Id: I267f3a5923e7154c72d18d76ecab1a9b1a0ec472
 VERSION
2022/01/06 13:12:15 $ git codereview mail -trybot -trust
2022/01/06 13:12:15 command failed: exit status 2
flag provided but not defined: -trust
Usage: /usr/local/google/home/amedee/bin/git-codereview mail [-n] [-v] [-r reviewer,...] [-cc mail,...] [-topic topic] [-trybot] [-hashtag tag,...] [commit]
2022/01/06 13:12:15

PANIC: command failed

goroutine 1 [running]:
runtime/debug.Stack()
	/usr/lib/google-golang/src/runtime/debug/stack.go:24 +0x65
main.(*Work).finally(0xc0a56b8ea0)
	/usr/local/google/home/amedee/Code/build/cmd/releasebot/main.go:445 +0x3e
panic({0xbcb580, 0xdc2840})
	/usr/lib/google-golang/src/runtime/panic.go:1038 +0x215
main.(*runner).run(0xc08d8e5c78, {0xc08d8e5d08, 0xc08d8e5bf0, 0xcf097e})
	/usr/local/google/home/amedee/Code/build/cmd/releasebot/main.go:471 +0xab
main.(*Work).writeVersion(0xc0a56b8ea0)
	/usr/local/google/home/amedee/Code/build/cmd/releasebot/main.go:768 +0x617
main.(*Work).doRelease(0xc0a56b8ea0)
	/usr/local/google/home/amedee/Code/build/cmd/releasebot/main.go:542 +0x385
main.main()
	/usr/local/google/home/amedee/Code/build/cmd/releasebot/main.go:198 +0xa0a

Log
2022/01/06 13:17:14 starting
2022/01/06 13:17:14 working in /usr/local/google/home/amedee/go-releasebot-work/go1.16.13
2022/01/06 13:17:14 $ git fetch origin master
2022/01/06 13:17:14 $ git fetch origin release-branch.go1.16
2022/01/06 13:17:14 $ git clone --reference /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitmirror -b release-branch.go1.16 https://go.googlesource.com/go /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitwork
2022/01/06 13:17:15 $ git codereview change relwork
2022/01/06 13:17:16 $ git config gc.auto 0
2022/01/06 13:17:16 an associated security release branch "release-branch.go1.16-security" does not exist; assuming it has been merged and deleted, so proceeding as usual
2022/01/06 13:17:16 $ git rev-parse go1.16.13
2022/01/06 13:17:16 Release status issue title: "all: Go 1.16.13 release status"
2022/01/06 13:17:16 Release status issue: https://golang.org/issue/50476
2022/01/06 13:17:16 $ git add VERSION
2022/01/06 13:17:16 $ git commit -m go1.16.13

Change-Id: I267f3a5923e7154c72d18d76ecab1a9b1a0ec472
 VERSION
2022/01/06 13:17:17 $ git codereview mail -trybot -trust
2022/01/06 13:17:20 $ go clean -modcache
2022/01/06 13:17:20 $ go install golang.org/x/build/cmd/release@latest
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target src -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-amd64-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-386-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target freebsd-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-s390x -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-arm64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target darwin-arm64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-ppc64le -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target darwin-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-armv6l -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:17:41 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target freebsd-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:18:57 release -target="src": build succeeded (after 0 retries)
2022/01/06 13:21:10 release -target="linux-ppc64le": build succeeded (after 0 retries)
2022/01/06 13:22:29 release -target="linux-s390x": build succeeded (after 0 retries)
2022/01/06 13:28:04 release -target="linux-arm64": build succeeded (after 0 retries)
2022/01/06 13:30:19 release -target="darwin-amd64": build succeeded (after 0 retries)
2022/01/06 13:30:19 release -target="linux-armv6l": build succeeded (after 0 retries)
2022/01/06 13:31:48 release -target="windows-amd64-longtest" did not produce expected output files [go1.16.13.windows-amd64-longtest.test-only]:
error from cmd/release binary = <nil>
output from cmd/release binary:
2022/01/06 13:17:41 windows-amd64-longtest: Start.
2022/01/06 13:17:41 windows-amd64-longtest: Creating buildlet.
2022/01/06 13:18:28 windows-amd64-longtest: Pushing source to buildlet.
2022/01/06 13:18:36 windows-amd64-longtest: Installing go1.4.
2022/01/06 13:18:38 windows-amd64-longtest: Writing VERSION file.
2022/01/06 13:18:38 windows-amd64-longtest: Cleaning goroot (pre-build).
2022/01/06 13:18:38 windows-amd64-longtest: Building (make.bash only).
2022/01/06 13:20:21 windows-amd64-longtest: Cleaning goroot (post-build).
2022/01/06 13:20:21 windows-amd64-longtest: Pushing and running releaselet.
2022/01/06 13:24:08 windows-amd64-longtest: Cleaning workdir.
2022/01/06 13:24:09 windows-amd64-longtest: Installing go1.4 (second time, for all.bash).
2022/01/06 13:24:12 windows-amd64-longtest: Building (all.bash to ensure tests pass).
2022/01/06 13:31:48 windows-amd64-longtest: Error: Build failed: exit status 1
Output:
Building Go cmd/dist using C:\workdir\go1.4
Building Go toolchain1 using C:\workdir\go1.4.

Building Go toolchain2 using go_bootstrap and Go toolchain1.
Building Go toolchain3 using go_bootstrap and Go toolchain2.
Building packages and commands for windows/amd64.

##### Testing packages.
ok  	archive/tar	0.063s
ok  	archive/zip	55.343s
ok  	bufio	0.117s
ok  	bytes	2.044s
ok  	compress/bzip2	0.113s
ok  	compress/flate	14.528s
ok  	compress/gzip	0.235s
ok  	compress/lzw	0.162s
ok  	compress/zlib	1.746s
ok  	container/heap	0.039s
ok  	container/list	0.032s
ok  	container/ring	0.031s
ok  	context	0.244s
ok  	crypto	0.037s
ok  	crypto/aes	0.052s
ok  	crypto/cipher	0.262s
ok  	crypto/des	0.040s
ok  	crypto/dsa	17.195s
ok  	crypto/ecdsa	6.126s
ok  	crypto/ed25519	0.110s
ok  	crypto/elliptic	2.807s
ok  	crypto/hmac	0.035s
ok  	crypto/internal/subtle	0.044s
ok  	crypto/md5	0.029s
ok  	crypto/rand	0.231s
ok  	crypto/rc4	0.078s
ok  	crypto/rsa	0.926s
ok  	crypto/sha1	0.042s
ok  	crypto/sha256	0.027s
ok  	crypto/sha512	0.039s
ok  	crypto/subtle	0.062s
ok  	crypto/tls	6.160s
ok  	crypto/x509	3.278s
ok  	database/sql	1.563s
ok  	database/sql/driver	0.040s
ok  	debug/dwarf	0.047s
ok  	debug/elf	0.051s
ok  	debug/gosym	3.730s
ok  	debug/macho	0.034s
ok  	debug/pe	7.960s
ok  	debug/plan9obj	0.027s
ok  	embed/internal/embedtest	0.035s
ok  	encoding/ascii85	0.030s
ok  	encoding/asn1	0.038s
ok  	encoding/base32	0.104s
ok  	encoding/base64	0.038s
ok  	encoding/binary	0.053s
ok  	encoding/csv	0.047s
ok  	encoding/gob	0.059s
ok  	encoding/hex	0.047s
ok  	encoding/json	2.146s
ok  	encoding/pem	0.055s
ok  	encoding/xml	0.051s
ok  	errors	0.042s
ok  	expvar	0.043s
ok  	flag	0.183s
ok  	fmt	0.142s
ok  	go/ast	0.049s
ok  	go/build	1.677s
ok  	go/build/constraint	0.027s
ok  	go/constant	0.043s
ok  	go/doc	0.180s
ok  	go/format	0.061s
ok  	go/importer	0.320s
ok  	go/internal/gccgoimporter	0.047s
ok  	go/internal/gcimporter	5.388s
ok  	go/internal/srcimporter	7.362s
ok  	go/parser	0.061s
ok  	go/printer	0.467s
ok  	go/scanner	0.039s
ok  	go/token	0.052s
ok  	go/types	21.657s
ok  	hash	0.039s
ok  	hash/adler32	0.042s
ok  	hash/crc32	0.058s
ok  	hash/crc64	0.031s
ok  	hash/fnv	0.029s
ok  	hash/maphash	167.802s
ok  	html	0.045s
ok  	html/template	0.454s
ok  	image	0.357s
ok  	image/color	0.054s
ok  	image/draw	0.101s
ok  	image/gif	0.808s
ok  	image/jpeg	0.253s
ok  	image/png	0.709s
ok  	index/suffixarray	91.623s
ok  	internal/cpu	0.037s
ok  	internal/execabs	0.035s
ok  	internal/fmtsort	0.047s
ok  	internal/poll	0.871s
ok  	internal/profile	0.041s
ok  	internal/reflectlite	0.191s
ok  	internal/singleflight	0.045s
ok  	internal/syscall/windows	0.074s
ok  	internal/syscall/windows/registry	0.032s
ok  	internal/trace	2.089s
ok  	internal/unsafeheader	0.037s
ok  	internal/xcoff	0.044s
ok  	io	0.124s
ok  	io/fs	0.029s
ok  	io/ioutil	0.032s
ok  	log	0.042s
ok  	math	0.030s
ok  	math/big	4.891s
ok  	math/bits	0.059s
ok  	math/cmplx	0.031s
ok  	math/rand	7.410s
ok  	mime	0.071s
ok  	mime/multipart	1.029s
ok  	mime/quotedprintable	0.760s
--- FAIL: TestDialerFallbackDelay (0.67s)
    dial_test.go:433: #0: got 169.9232ms; want <= 95ms
FAIL
FAIL	net	68.943s
ok  	net/http	91.663s
ok  	net/http/cgi	0.536s
ok  	net/http/cookiejar	0.097s
ok  	net/http/fcgi	0.048s
ok  	net/http/httptest	2.407s
ok  	net/http/httptrace	0.032s
ok  	net/http/httputil	1.039s
ok  	net/http/internal	0.037s
ok  	net/http/pprof	5.350s
ok  	net/internal/socktest	0.032s
ok  	net/mail	0.030s
ok  	net/rpc	0.086s
ok  	net/rpc/jsonrpc	0.053s
ok  	net/smtp	0.052s
ok  	net/textproto	0.052s
ok  	net/url	0.032s
ok  	os	131.212s
ok  	os/exec	5.826s
ok  	os/signal	1.797s
ok  	os/user	0.045s
ok  	path	0.025s
ok  	path/filepath	0.686s
ok  	plugin	0.027s
ok  	reflect	1.163s
ok  	regexp	29.139s
ok  	regexp/syntax	0.386s
ok  	runtime	306.232s
ok  	runtime/debug	0.138s
ok  	runtime/internal/atomic	1.505s
ok  	runtime/internal/math	0.024s
ok  	runtime/internal/sys	0.029s
ok  	runtime/metrics	0.027s
ok  	runtime/pprof	65.116s
ok  	runtime/trace	21.138s
ok  	sort	0.928s
ok  	strconv	1.963s
ok  	strings	1.184s
ok  	sync	7.580s
ok  	sync/atomic	2.961s
ok  	syscall	0.025s
ok  	testing	4.985s
ok  	testing/fstest	0.088s
ok  	testing/iotest	0.027s
ok  	testing/quick	0.068s
ok  	text/scanner	0.031s
ok  	text/tabwriter	0.081s
ok  	text/template	1.336s
ok  	text/template/parse	0.064s
ok  	time	9.889s
ok  	unicode	0.030s
ok  	unicode/utf16	0.029s
ok  	unicode/utf8	0.048s
ok  	cmd/addr2line	6.111s
ok  	cmd/api	21.601s
ok  	cmd/asm/internal/asm	1.321s
ok  	cmd/asm/internal/lex	0.040s
ok  	cmd/compile	9.326s
ok  	cmd/compile/internal/gc	32.635s
ok  	cmd/compile/internal/logopt	1.389s
ok  	cmd/compile/internal/ssa	77.068s
ok  	cmd/compile/internal/syntax	7.477s
ok  	cmd/compile/internal/test	0.035s
ok  	cmd/compile/internal/types	0.034s
ok  	cmd/cover	4.829s
ok  	cmd/doc	0.263s
ok  	cmd/fix	4.510s
ok  	cmd/go	176.126s
ok  	cmd/go/internal/auth	0.058s
ok  	cmd/go/internal/cache	145.610s
ok  	cmd/go/internal/fsys	0.209s
ok  	cmd/go/internal/generate	0.069s
ok  	cmd/go/internal/get	0.069s
ok  	cmd/go/internal/imports	0.062s
ok  	cmd/go/internal/load	0.060s
ok  	cmd/go/internal/lockedfile	2.942s
ok  	cmd/go/internal/lockedfile/internal/filelock	0.105s
ok  	cmd/go/internal/modconv	0.047s
ok  	cmd/go/internal/modfetch	1.570s
ok  	cmd/go/internal/modfetch/codehost	0.036s
ok  	cmd/go/internal/modfetch/zip_sum_test	0.033s
ok  	cmd/go/internal/modload	0.116s
ok  	cmd/go/internal/mvs	0.034s
ok  	cmd/go/internal/par	0.184s
ok  	cmd/go/internal/renameio	91.418s
ok  	cmd/go/internal/search	0.082s
ok  	cmd/go/internal/str	0.077s
ok  	cmd/go/internal/test	0.606s
ok  	cmd/go/internal/txtar	0.033s
ok  	cmd/go/internal/vcs	0.371s
ok  	cmd/go/internal/web	0.094s
ok  	cmd/go/internal/work	0.155s
ok  	cmd/gofmt	9.744s
ok  	cmd/internal/archive	2.465s
ok  	cmd/internal/buildid	0.333s
ok  	cmd/internal/dwarf	0.050s
ok  	cmd/internal/edit	0.091s
ok  	cmd/internal/goobj	0.085s
ok  	cmd/internal/moddeps	4.923s
ok  	cmd/internal/obj	0.554s
ok  	cmd/internal/obj/ppc64	1.144s
ok  	cmd/internal/obj/riscv	3.169s
ok  	cmd/internal/obj/s390x	0.074s
ok  	cmd/internal/obj/x86	17.474s
ok  	cmd/internal/objabi	0.068s
ok  	cmd/internal/pkgpath	0.692s
ok  	cmd/internal/src	0.052s
ok  	cmd/internal/sys	0.100s
ok  	cmd/internal/test2json	0.329s
ok  	cmd/link	52.277s
ok  	cmd/link/internal/benchmark	0.084s
ok  	cmd/link/internal/ld	52.636s
ok  	cmd/link/internal/loader	0.168s
ok  	cmd/nm	16.922s
ok  	cmd/objdump	17.285s
ok  	cmd/pack	15.006s
ok  	cmd/trace	0.625s
ok  	cmd/vet	19.925s
FAIL
go tool dist: Failed: exit status 1
2022/01/06 13:31:48 release -target="windows-amd64-longtest": waiting a bit and trying again
2022/01/06 13:32:31 release -target="darwin-arm64": build succeeded (after 0 retries)
2022/01/06 13:32:48 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/7f12f1e187b0286322aa97aa56d9249c114dbae6_3612422595 -rev 7f12f1e187b0286322aa97aa56d9249c114dbae6
2022/01/06 13:34:17 release -target="freebsd-386": build succeeded (after 0 retries)
2022/01/06 13:35:01 release -target="freebsd-amd64": build succeeded (after 0 retries)
2022/01/06 13:35:30 release -target="linux-amd64": build succeeded (after 0 retries)
2022/01/06 13:35:49 release -target="linux-386": build succeeded (after 0 retries)
2022/01/06 13:39:29 release -target="linux-amd64-longtest": build succeeded (after 0 retries)
2022/01/06 13:44:47 release -target="windows-386": build succeeded (after 0 retries)
2022/01/06 13:44:51 release -target="linux-386-longtest": build succeeded (after 0 retries)
2022/01/06 13:44:58 release -target="windows-amd64": build succeeded (after 0 retries)
2022/01/06 13:59:06 release -target="windows-amd64-longtest": build succeeded (after 1 retries)
2022/01/06 13:59:06

The prepare stage has completed.

Please review and submit https://go-review.googlesource.com/q/I267f3a5923e7154c72d18d76ecab1a9b1a0ec472
and then run the release stage.

Latest build: go1.16.13

src (tar.gz)
linux-386 (tar.gz)
linux-armv6l (tar.gz)
linux-amd64 (tar.gz)
linux-arm64 (tar.gz)
freebsd-386 (tar.gz)
freebsd-amd64 (tar.gz)
windows-386 (zip) (msi)
windows-amd64 (zip) (msi)
darwin-amd64 (tar.gz)
darwin-arm64 (tar.gz)
linux-s390x (tar.gz)
linux-ppc64le (tar.gz)
linux-386-longtest (test only) - ok
linux-amd64-longtest (test only) - ok
windows-amd64-longtest (test only) - ok

Log
2022/01/06 14:08:35 starting
2022/01/06 14:08:35 working in /usr/local/google/home/amedee/go-releasebot-work/go1.16.13
2022/01/06 14:08:35 $ git fetch origin master
2022/01/06 14:08:35 $ git fetch origin release-branch.go1.16
2022/01/06 14:08:36 $ git clone --reference /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitmirror -b release-branch.go1.16 https://go.googlesource.com/go /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gitwork
2022/01/06 14:08:37 $ git codereview change relwork
2022/01/06 14:08:38 $ git config gc.auto 0
2022/01/06 14:08:38 an associated security release branch "release-branch.go1.16-security" does not exist; assuming it has been merged and deleted, so proceeding as usual
2022/01/06 14:08:38 Release status issue title: "all: Go 1.16.13 release status"
2022/01/06 14:08:38 Release status issue: https://golang.org/issue/50476
2022/01/06 14:08:38 $ git rev-parse go1.16.13
2022/01/06 14:08:47 $ git tag go1.16.13 378766af9ed0f2e28d67c2b50e73db7573656669
2022/01/06 14:08:47 $ git push origin go1.16.13
2022/01/06 14:08:49 $ go clean -modcache
2022/01/06 14:08:49 $ go install golang.org/x/build/cmd/release@latest
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-armv6l -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target src -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-arm64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target freebsd-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target darwin-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target darwin-arm64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-amd64-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-s390x -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-ppc64le -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-386-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target freebsd-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:08:58 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:10:40 release -target="linux-arm64": build succeeded (after 0 retries)
2022/01/06 14:11:04 release -target="linux-armv6l": build succeeded (after 0 retries)
2022/01/06 14:14:34 release -target="darwin-amd64": build succeeded (after 0 retries)
2022/01/06 14:14:35 release -target="src": build succeeded (after 0 retries)
2022/01/06 14:15:16 release -target="freebsd-amd64": build succeeded (after 0 retries)
2022/01/06 14:15:38 release -target="darwin-arm64": build succeeded (after 0 retries)
2022/01/06 14:15:54 release -target="freebsd-386": build succeeded (after 0 retries)
2022/01/06 14:15:58 release -target="linux-386-longtest": build succeeded (after 0 retries)
2022/01/06 14:16:11 release -target="linux-amd64-longtest": build succeeded (after 0 retries)
2022/01/06 14:17:21 release -target="linux-386": build succeeded (after 0 retries)
2022/01/06 14:17:23 release -target="linux-amd64": build succeeded (after 0 retries)
2022/01/06 14:17:54 release -target="linux-s390x" did not produce expected output files [go1.16.13.linux-s390x.tar.gz]:
error from cmd/release binary = <nil>
output from cmd/release binary:
2022/01/06 14:08:58 linux-s390x: Start.
2022/01/06 14:08:58 linux-s390x: Creating buildlet.
2022/01/06 14:17:35 linux-s390x: Pushing source to buildlet.
2022/01/06 14:17:42 linux-s390x: Writing VERSION file.
2022/01/06 14:17:42 linux-s390x: Cleaning goroot (pre-build).
2022/01/06 14:17:42 linux-s390x: Building (make.bash only).
2022/01/06 14:17:54 linux-s390x: Error: error copying response: unexpected EOF
2022/01/06 14:17:54 release -target="linux-s390x": waiting a bit and trying again
2022/01/06 14:17:54 release -target="linux-ppc64le" did not produce expected output files [go1.16.13.linux-ppc64le.tar.gz]:
error from cmd/release binary = <nil>
output from cmd/release binary:
2022/01/06 14:08:58 linux-ppc64le: Start.
2022/01/06 14:08:58 linux-ppc64le: Creating buildlet.
2022/01/06 14:14:35 linux-ppc64le: Pushing source to buildlet.
2022/01/06 14:14:41 linux-ppc64le: Writing VERSION file.
2022/01/06 14:14:41 linux-ppc64le: Cleaning goroot (pre-build).
2022/01/06 14:14:41 linux-ppc64le: Building (make.bash only).
2022/01/06 14:17:54 linux-ppc64le: Error: error copying response: unexpected EOF
2022/01/06 14:17:54 release -target="linux-ppc64le": waiting a bit and trying again
2022/01/06 14:17:54 release -target="windows-amd64" did not produce expected output files [go1.16.13.windows-amd64.zip go1.16.13.windows-amd64.msi]:
error from cmd/release binary = <nil>
output from cmd/release binary:
2022/01/06 14:08:58 windows-amd64: Start.
2022/01/06 14:08:58 windows-amd64: Creating buildlet.
2022/01/06 14:13:20 windows-amd64: Pushing source to buildlet.
2022/01/06 14:13:33 windows-amd64: Installing go1.4.
2022/01/06 14:13:36 windows-amd64: Writing VERSION file.
2022/01/06 14:13:36 windows-amd64: Cleaning goroot (pre-build).
2022/01/06 14:13:36 windows-amd64: Building (make.bash only).
2022/01/06 14:16:31 windows-amd64: Building race detector.
2022/01/06 14:16:57 windows-amd64: Cleaning goroot (post-build).
2022/01/06 14:16:57 windows-amd64: Pushing and running releaselet.
2022/01/06 14:17:54 releaselet failed: error copying response: unexpected EOF
2022/01/06 14:17:54 windows-amd64: Error: error copying response: unexpected EOF
2022/01/06 14:17:54 release -target="windows-amd64": waiting a bit and trying again
2022/01/06 14:17:54 release -target="windows-386" did not produce expected output files [go1.16.13.windows-386.zip go1.16.13.windows-386.msi]:
error from cmd/release binary = <nil>
output from cmd/release binary:
2022/01/06 14:08:58 windows-386: Start.
2022/01/06 14:08:58 windows-386: Creating buildlet.
2022/01/06 14:12:34 windows-386: Pushing source to buildlet.
2022/01/06 14:12:42 windows-386: Installing go1.4.
2022/01/06 14:12:45 windows-386: Writing VERSION file.
2022/01/06 14:12:45 windows-386: Cleaning goroot (pre-build).
2022/01/06 14:12:45 windows-386: Building (make.bash only).
2022/01/06 14:15:15 windows-386: Cleaning goroot (post-build).
2022/01/06 14:15:15 windows-386: Pushing and running releaselet.
2022/01/06 14:17:54 releaselet failed: error copying response: unexpected EOF
2022/01/06 14:17:54 windows-386: Error: error copying response: unexpected EOF
2022/01/06 14:17:54 release -target="windows-386": waiting a bit and trying again
2022/01/06 14:17:54 release -target="windows-amd64-longtest" did not produce expected output files [go1.16.13.windows-amd64-longtest.test-only]:
error from cmd/release binary = <nil>
output from cmd/release binary:
2022/01/06 14:08:58 windows-amd64-longtest: Start.
2022/01/06 14:08:58 windows-amd64-longtest: Creating buildlet.
2022/01/06 14:12:25 windows-amd64-longtest: Pushing source to buildlet.
2022/01/06 14:12:30 windows-amd64-longtest: Installing go1.4.
2022/01/06 14:12:33 windows-amd64-longtest: Writing VERSION file.
2022/01/06 14:12:33 windows-amd64-longtest: Cleaning goroot (pre-build).
2022/01/06 14:12:33 windows-amd64-longtest: Building (make.bash only).
2022/01/06 14:14:24 windows-amd64-longtest: Cleaning goroot (post-build).
2022/01/06 14:14:25 windows-amd64-longtest: Pushing and running releaselet.
2022/01/06 14:17:54 releaselet failed: error copying response: unexpected EOF
2022/01/06 14:17:54 windows-amd64-longtest: Error: error copying response: unexpected EOF
2022/01/06 14:17:54 release -target="windows-amd64-longtest": waiting a bit and trying again
2022/01/06 14:18:54 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-s390x -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:18:54 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target linux-ppc64le -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:18:54 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:18:54 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-386 -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:18:54 $ /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/gopath/bin/release -target windows-amd64-longtest -user amedee -version go1.16.13 -staging_dir /usr/local/google/home/amedee/go-releasebot-work/go1.16.13/release-staging/378766af9ed0f2e28d67c2b50e73db7573656669_1649654981 -rev 378766af9ed0f2e28d67c2b50e73db7573656669 -skip_tests
2022/01/06 14:25:46 release -target="windows-amd64-longtest": build succeeded (after 1 retries)
2022/01/06 14:26:19 release -target="windows-386": build succeeded (after 1 retries)
2022/01/06 14:26:35 release -target="linux-ppc64le": build succeeded (after 1 retries)
2022/01/06 14:28:02 release -target="windows-amd64": build succeeded (after 1 retries)
2022/01/06 14:43:35 release -target="linux-s390x": build succeeded (after 1 retries)
2022/01/06 14:43:39 creating milestone titled "Go1.16.14"
2022/01/06 14:43:39 changing milestone of issue 43941 to Go1.16.14
2022/01/06 14:43:41 changing milestone of issue 50245 to Go1.16.14
2022/01/06 14:43:41 closing milestone Go1.16.13
2022/01/06 14:43:42

The release stage has completed. Thanks for riding with releasebot today!

Please refer to the playbook for the next steps.


Doesn't work on mobile

Hello, i followed the VanillaJS example guide. And everything works fine on Desktop, but not on mobile. This is my current code.
try {         web3Modal = new Web3Modal({             network: "binance", // replace mainnet to binance             providerOptions, // required             disableInjectedProvider: false, // optional. For MetaMask / Brave / Opera.         });                     console.log(web3Modal)             try {                 web3Modal.resetState()                 provider = await web3Modal.connect();                 console.log(provider)             } catch(e) {                 console.log("Could not get a wallet connection", e);                 return;             }

With stable version 2.0.0 of Web3Modal now released, we are officially dropping support for version 1.x
Due to this this issue/pr was marked for closing. It is highly recommended to upgrade as 2.x will be receiving further updates that will enable functionality for some of our newer sdks like auth and push as well as support for WalletConnect v2 (See this post about WalletConnect v1 being deprecated https://medium.com/walletconnect/walletconnect-v1-0-sunset-notice-and-migration-schedule-8af9d3720d2e)
If you need to continue using Web3Modal 1.x and require this feature/fix implemented, we suggest adding it via forking V1 branch.


Display reasons why module was included

First of all, thanks for a wonderful tool! It has been super helpful in our attempts to reduce the bundle size of our main application.
One of the things that was slightly difficult for me though is figuring out why stuff was in the bundle. I started using the reasons metadata in stats.json to trace back the origins, but it's quite cumbersome to grep a JSON file. I thought it would be helpful to have this in the UI as well.
Here's what the change does:
Search for modules.
The user is a presented with an input field in the sidebar, which will allow them to filter a list of modules in the bundle.
Display the reasons a module was included
For every module, the reasons why it was included in the displayed in the module info block. The weird CSS you see in ModuleButton is used to fake a text-overflow from the start rather than the end, because the latter part of the module's path is more identifying than the first few folders.
Adds the concept of selected modules.
This allows the user to select or pin a module, and have its info displayed in the sidebar. There are three ways to select a module:

Single-clicking a module in the treemap (note: this changes current behaviour, where a single click triggers zooming in on that module - that is now possible by a double click).
Entering a search query in the input field, and clicking one of the modules that are listed.
Clicking on a reason of the currently displayed module.

Once a module is selected, window.location.hash is updated with the id of the module. If the user has selected a module group rather than a module, the name of the module is prefilled in the input field to allow the user to search for modules in that group.
The user can deselect a module by clicking on the close button of the sidebar, or they can use a back button that is displayed to go the previously selected module or query. They can also just use browser navigation to quickly navigate back and forth between selected modules. This allows the user to quickly do drill-downs of reasons why modules were included.

Hi! Thanks for submitting this PR :blush:. Sorry for replying a bit late — I've been thinking about this PR for quite some time and figuring out a good response.
First of all, I really like this feature. I think it brings a lot of additional value that was previously quite inaccessible.
The size of this PR is quite heavy, though, so reviewing this code would take quite a big amount of time. There are a few factors why I haven't been able to review this properly as of yet:

All of the changes are in one commit — this means I have to check the entire diff at once instead of small chunks of implementation in steps
We don't have any UI tests — seeing as this brings in a major new UI interaction pattern, I fear the worst scenario where this creates much more maintentance load than other features we support.
This changes the existing interaction behavior, and I haven't been the one implementing the old behavior so I'm a bit hesitant in making decisions if this new behavior is what we want.
The sizes of some component files are getting so large that it's getting increasingly hard to get a full picture of all the things that are happening in those components.
This feature brings in a secondary, global state container — the window.location.hash.
I'm not sure how @th0r wants us to progress here, or what he thinks. I'm not sure what kind of decisions I'm free to make / how much does @th0r trust me in reviewing and maintaining this package.

All of these make it a bit more challenging to jump into this PR.
However, I really do think that this feature would be a good addition. I hope I'm able to shed some light into why this is a bit difficult PR to review. Do you have any suggestions into how we could make this a bit simpler for me to look through?

Thanks for replying!

All of the changes are in one commit — this means I have to check the entire diff at once instead of small chunks of implementation in steps

No worries, I can split them up I think. Always a bit of a guess whether commits should be squashed or not.

We don't have any UI tests — seeing as this brings in a major new UI interaction pattern, I fear the worst scenario where this creates much more maintenance load than other features we support.

Understood. If it's necessary I can add some UI tests but it will greatly increase the surface of the PR :).

The sizes of some component files are getting so large that it's getting increasingly hard to get a full picture of all the things that are happening in those components.

I think you're referring to ModulesTreemap? That is getting quite big indeed. I can refactor, but same issue here as well - increases the surface of the PR.

This feature brings in a secondary, global state container — the window.location.hash.

Could you elaborate a bit on why you think this is an issue?

This changes the existing interaction behavior, and I haven't been the one implementing the old behavior so I'm a bit hesitant in making decisions if this new behavior is what we want.
I'm not sure how @th0r wants us to progress here, or what he thinks. I'm not sure what kind of decisions I'm free to make / how much does @th0r truAll of these make it a bit more challenging to jump into this PR.
However, I really do think that this feature would be a good addition. I hope I'm able to shed some light into why this is a bit difficult PR to review. Do you have any suggestions into how we could make this a bit simpler for me to look through?st me in reviewing and maintaining this package.

As far as the last question, I can split it up into smaller commits, and provide a technical overview of the PR (I've basically only described the feature now). I think refactoring and/or adding tests will only make it more difficult to get reviewed/merged. The UI code is still quite simple.
Before I put it in the effort it's probably a good idea to settle on whether this is the way forward. It's been extremely helpful for me the last few days in figuring out why things end up in our bundle.
Maybe we can collect some more feedback before making a decision. I can do a write-up on Medium and ask people to test-drive it.

This feature brings in a secondary, global state container — the window.location.hash.

Could you elaborate a bit on why you think this is an issue?

It just makes it a bit more difficult to review and test the implications of this and assert that I have figured out the data flow correctly for it. Compared to just looking at this.state and this.props, this is just a bit more to take in at once.
I definitely don't mean that it's a bad thing that this feature leverages window.location.hash. It just adds a dash more complexity :)

Would saving the hash to state on hashchange (setState({ hash: window.location.hash }), and inferring the selectedModule in render(),
rather than imperatively updating state with selectedModule, help?
On Wed, Jun 7, 2017 at 9:18 AM Vesa Laakso<EMAIL_ADDRESS>wrote:

This feature brings in a secondary, global state container — the
window.location.hash.
Could you elaborate a bit on why you think this is an issue?
It just makes it a bit more difficult to review and test the implications
of this and assert that I have figured out the data flow correctly for it.
Compared to just looking at this.state and this.props, this is just a bit
more to take in at once.
I definitely don't mean that it's a bad thing that this feature leverages
window.location.hash. It just adds a dash more complexity :)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/th0r/webpack-bundle-analyzer/pull/85#issuecomment-306708742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVh3LDy_6xFqwcxbpXz6d63SMxg5XF5ks5sBk68gaJpZM4NvTHy
.

All of the changes are in one commit — this means I have to check the entire diff at once instead of small chunks of implementation in steps

No worries, I can split them up I think. Always a bit of a guess whether commits should be squashed or not.

Yeah, I don't know about other people but I find it easier to read large-ish PRs with one step at a time, and should I want to squash things, I could do it at merge-time :)

Before I put it in the effort it's probably a good idea to settle on whether this is the way forward. It's been extremely helpful for me the last few days in figuring out why things end up in our bundle.
Maybe we can collect some more feedback before making a decision. I can do a write-up on Medium and ask people to test-drive it.

I'd be curious to hear what @th0r feels about this feature. I do think that this is a very good addition to the plugin. I think it's just about maintenance burden on this one, not necessarily whether people wouldn't consider this a good addition.

Would saving the hash to state on hashchange (setState({ hash: window.location.hash }), and inferring the selectedModule in render(),
rather than imperatively updating state with selectedModule, help?

That could definitely improve things. If we're able to move global hash accessing to the edges of the components and use state & props, it would be great.
I wouldn't even mind if we'd have a separate wrapper component in between that would only handle the integration with window.location.hash and pass some useful value down to other components. This way that component would only have to care about one thing, and we'd have one less thing to worry about in the ModulesTreemap component.

We don't have any UI tests — seeing as this brings in a major new UI interaction pattern, I fear the worst scenario where this creates much more maintenance load than other features we support.

Understood. If it's necessary I can add some UI tests but it will greatly increase the surface of the PR :).

Yeah, that is a tough place to be in. Do you think we could iterate on a good testing strategy outside of this PR? For example, creating a new PR that starts from this branch so we would be able to look at figuring out a good test strategy outside of this new feature addition?

Hi guys!
@dgieselaar Thanks for a great PR! Information about reasons is definitely the next big thing I want to add to this module and I even have some working code already. The main problem here is the clean intuitive and convenient UI.
Here are my thoughts on UI requirements:

Some interaction with module in a treemap should show it's details including reasons list.
Reasons list should allow to show reason module in a treemap (focus on it): move viewport to it, highlight and zoom if needed.
Reasons list should allow to dig into reason module (and move back to parent module?)

And here are possible solutions:

Cmd+Click on module in a treemap activates it: focuses treemap on it and opens right sidebar with module details. Thus, all the information about bundles and treemap will be located in the left sidebar and all the info about concrete active module will be located in the right one. It will also allow to add any additional module information in future.
Hovering a reason in the list will focus it in the treemap.
Clicking a reason in the list will activate its module.

The blind spot here is moving back to original active module, but I think it can be solved with @dgieselaar's approach that uses browser history.
What do you think guys?

Hi @th0r! I think these are the only differences between your list of requirements and my implementation:

Selecting a module via the tree map is just click rather than cmd/ctrl + click. I actually think it makes more sense to select on click, because of the added value of selecting a module (which IMO is bigger than zooming in).
Selecting a module doesn't zoom in. I'm not really sold on the benefits of zooming in automatically, but I don't really mind changing it to zoom in either.

Other than that, the drilldown, and navigating back and forth etc, should work. Have you tried it out?

Selecting a module via the tree map is just click rather than cmd/ctrl + click. I actually think it makes more sense to select on click, because of the added value of selecting a module (which IMO is bigger than zooming in).

Not sure here.  And I don't think showing module details are going to be used more frequently. And the second concern is we will change default behavior.
P.S. Double-click to zoom doesn't work for me in your branch (Macbook, touchpad).

Selecting a module doesn't zoom in. I'm not really sold on the benefits of zooming in automatically, but I don't really mind changing it to zoom in either.

I'm not sure we need to zoom in but moving to the viewport and highlighting is a must-have.

Other than that, the drilldown, and navigating back and forth etc, should work. Have you tried it out?

Yes, I tried but didn't get what moving back and forth does. Seems line nothing changes in the UI.

I think these are the only differences between your list of requirements and my implementation

Also you use the same left sidebar. I was talking about adding the right one to show details about active module.

Not sure here.  And I don't think showing module details are going to be used more frequently. And the second concern is we will change default behavior.

Alright. How about zooming in on a selected module? A compromise :). If not acceptable, how would you prefer the user to select a module, double click?

P.S. Double-click to zoom doesn't work for me in your branch (Macbook, touchpad).

Will investigate.

I'm not sure we need to zoom in but moving into viewport and highlighting is a must-have.

When you say highlight, do you mean the same behaviour as on hover, namely the module lighting up a bit?

Yes, I tried but didn't get what moving back and forth does. Seems line nothing changes in the UI.

When you say moving back and forth, do you mean navigating back and forth between URLs? If so, it should select the module based on the hash in the URL.

Also you use the same left sidebar. I was talking about adding the right one to show details about active module.

Fair point! Do you think that it's better to have separate sidebars? Personally, I develop in split-screen mode, so my browser window is more tablet size, and having two sidebars take up a lot of horizontal space would make things quite hard to use.

Alright. How about zooming in on a selected module? A compromise :). If not acceptable, how would you prefer the user to select a module, double click?

Double click (but seems like it has some issues) or cmd/ctrl + click

When you say highlight, do you mean the same behaviour as on hover, namely the module lighting up a bit?

I would change outline color to something noticeable.

When you say moving back and forth, do you mean navigating back and forth between URLs? If so, it should select the module based on the hash in the URL. Is this not happening for you?

It changes URL in the browser, the value in the search and found modules. But how it helps to figure out module reasons?

Fair point! Do you think that it's better to have separate sidebars? Personally, I develop in split-screen mode, so my browser window is more tablet size, and having two sidebars take up a lot of horizontal space would make things quite hard to use.

Actually, when you selecting a module there is no point in showing left sidebar - only right sidebar will be visible with details module information in it.

It changes URL in the browser, the value in the search and found modules. But how it helps to figure out module reasons?

The module reasons are displayed below the selected module.  Might be a bug somewhere, could you make a screenshot?

Haha, well, that explains, a bug indeed. Seems like the names don't correspond. Could you send me the stats file?

https://www.dropbox.com/s/qdm8abmu179pnom/stats.json?dl=0

Thanks! Will report back later.
On Thu, Jun 8, 2017 at 10:41 AM Yuriy Grunin<EMAIL_ADDRESS>wrote:

https://www.dropbox.com/s/qdm8abmu179pnom/stats.json?dl=0
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/th0r/webpack-bundle-analyzer/pull/85#issuecomment-307038832,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVh3O4IUxCaXl32DvFJqtBYLCb72gzEks5sB7OegaJpZM4NvTHy
.

Sorry, completely forgot about this! Moving it back to the top of my list :).

Hi @th0r, I made the following changes:

The bug which caused your modules not to be selected is fixed.
I've reverted the click-to-select change. The behaviour is now as it was: single select zooms in on a module. If event.ctrlKey or event.metaKey is true, it selects the module instead of zooming in.

I've not yet created a second sidebar. Can you try this out first and tell me what changes you'd like to see based on this?

Hi! Thanks for continuing work on this PR :) I'd like you to know that we haven't forgotten about this PR. It's just that this has lots of new changes, and we don't have any proper UI tests, that adding new features to the UI is starting to be much more scary maintainability-wise.
Would you happen to have any ideas on how we could possibly add even rudimentary UI tests for this?

hi, guys, I did something similar https://github.com/restrry/webpack-deps-tree what do you think about integrating that tool in webpack-bundle-analyzer ?

hi, guys, I did something similar https://github.com/restrry/webpack-deps-tree what do you think about integrating that tool in webpack-bundle-analyzer ?

Once we have #32 done, that visualization could be a new reporter that you could develop outside of this repo :)
But let's not hijack this PR to discuss this, though

Hi @dgieselaar, sorry for dragging this PR out for so long! The idea behind this PR is amazing, and would definitely be useful to have in some form.
However, with the upcoming version 3, I'm afraid we can't continue with this PR as it currently is. Hopefully in the future it will be simpler to experiment with new analysis tools and extra information. Right now, I'm concerned of the merge conflicts we'd have should we try to get this in before version 3.
I'll close this PR as there doesn't currently seem to be a way to get this in. Thank you for contributing, it has been a pleasure talking this idea through and I hope we'll see some version of this idea later in the future 💞

No problem, thanks for notifying me! I hope I can pick it up soon when I
have some time available.
On Sun, Feb 4, 2018, 11:16 Vesa Laakso<EMAIL_ADDRESS>wrote:

Hi @dgieselaar https://github.com/dgieselaar, sorry for dragging this
PR out for so long! The idea behind this PR is amazing, and would
definitely be useful to have in some form.
However, with the upcoming version 3, I'm afraid we can't continue with
this PR as it currently is. Hopefully in the future it will be simpler to
experiment with new analysis tools and extra information. Right now, I'm
concerned of the merge conflicts we'd have should we try to get this in
before version 3.
I'll close this PR as there doesn't currently seem to be a way to get this
in. Thank you for contributing, it has been a pleasure talking this idea
through and I hope we'll see some version of this idea later in the future
💞
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/webpack-contrib/webpack-bundle-analyzer/pull/85#issuecomment-362895962,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAVh3C0ytcPBjIEggZPinu5imdpU27xAks5tRYN_gaJpZM4NvTHy
.

Let's see how the code landscape looks like when I get v3 finished up. It might be a good idea to wait for v3 first before opening up this code again :relaxed:

FYI @dgieselaar, v3 has been released!

@swrobel yeah, I think @th0r will pick it up IIRC!

The version 3 I talked about 8 months ago didn't go so well and I had to scrap my PR. The other version 3 that was released is something else

Displaying import reasons is what I'm working on right now.


fixes for #120

they should work but I've probably messed something up with the git 💀

The change itself looks good, but you've also commited changing apollo.py extensions, removing config.example, and removing or adding some random blank lines to multiple files

The easiest way to fix this is probably to create a new branch and make the single change. Otherwise the random changes commit and the reverting commits will probably cause a merge conflict, or at least a bit of a mess.
Then either create a new PR or force push your new version to your remote branch.

Joke made me laugh so LGTM, besides what owen has said


formatting jsp code cause running errors.

Description
We usually use jstl or struts tags in jsp code, but tag's attribute value after beautified will be inserted some space which cause running errors.
For example, we entered the following code:
<a href="<s:url namespace="/taskdist" action="index"></s:url>" class="btn btn-primary" role="button">Task Index

after beautified, the attribute value of struts tags has been inserted a space, and the space cause running errors:
<a href="<s:url namespace=" /taskdist" action=" index"></s:url>" class="btn btn-primary" role="button">Task Index

Expected Results
The beautified code should have looked like:
<a href="<s:url namespace="/taskdist" action="index"></s:url>" class="btn btn-primary" role="button">Task Index

Steps to Reproduce

Add code to Atom editor
Run command Atom Beautify: Beautify Editor
This beautified code does not look right!

Would you mind generating Atom Beautify's debug.md file and pasting it into a gist?  This will help us identify which beautifier you are using and which grammar Atom thinks you are using.

@prettydiff Here is the gist url: https://gist.github.com/a3e4667be3dfd361dd26ee9243e930e5.

Pretty Diff defect.  I am working it now.

The problem is a collision with the quotes.  The challenge is that I can choose to support one of these, but not both:
<a attribute="<c:out value="place">something</c:out>">a thing

<a attribute="if (aa thing

The reason for the dichotomy is that each attribute contains a < within quotes.  In one case its a markup delimiter and in another case it isn't.  To make matters worse the JSP embedded tag use quotes for its attribute while it itself is quoted.  That means I have to expect that the attribute value is delimited by double quotes, contains an XML tag delimited by angle braces, and contains contains its own attributes delimited by double quotes.  I can parse this without collision, but only if I presume the angle braces must be delimiters for XML.
The only resolutions I can think of are:

Change your JSP attributes to be wrapped in single quotes.  I tried this in Pretty Diff and it instantly solved the problem.

Extend Pretty Diff to support embedded tags within attribute values.... but only if the attribute value begins with a delimiter and ends with a delimiter.  Meaning the following would still fail
<a myAttribute="<c:out cat="meow">furry climber">animal

This work is done.  I put in some extra effort to ensure that all code examples in my prior comment are possible.  The resolution is published to Pretty Diff release 2.1.1 but will not be available to Atom Beautify until I can release https://github.com/prettydiff/biddle

@prettydiff Thank you for resolving the problem.

Keeping everybody informed I have fixed biddle.  Check it out now - https://github.com/prettydiff/biddle
I will republish Pretty Diff using biddle in production tomorrow.  I am not ready to give it to Atom Beautify just yet though.  I actually need users to play around with this thing for a bit so that I can get a sense of where the pain points are and just how bad it works for fails for other people.  I wrote a getting started document at https://github.com/prettydiff/biddle/blob/master/documentation/gettingstarted.md
The documentation might be easier to read from the command line though as I included a markdown to CLI parser in biddle.  The number at the end defines the word wrap limit:
node biddle markdown documentation/gettingstarted.md 80


Create DataPalooza survey

copied last year's and made some tweaks.  Preview can be found here -> https://www.surveymonkey.com/r/Preview/?sm=fpwnIEdXQsswOZfZIVCeAd6W80cybUu9GlziLKglTJfJUkAt6d5fLjFEDurwFrg2&state=invite_modal

updated survey question asking for volunteers to have a spot for email collection for us to follow-up with that person.  The email field is not required


[DOC]: Fix broken link in script APIs section

What do you want to do?

[ ] Request a change to existing documentation

Please fix broken links in https://opensearch.org/docs/latest/opensearch/rest-api/_script-apis/index/
The links in the bulleted list of script capabilities (above the table of contents) each include a path component script-apis which is incorrect. Please change to _script-apis.

This has been completed.


Message property in template overwrites Message property in output

Which version of Serilog.Sinks.Grafana.Loki are you using?
v7.10
Which version of .NET are you using?
net5
Describe the bug
When using this sink to push to Loki, we get json data like so:
logger.LogInfo("Hello {Who}", world);

{
     "Message":  "Hello World",
     "MessageTemplate": "Hello {Who}",
     "Who": "World"
}

To Reproduce
But,
If the property is named "Message", you instead get the following output:
logger.LogInfo("Hello {Message}", world);

{
     "Message":  "World",
     "MessageTemplate": "Hello {Message}",
}

The entry for the formatted output has now been replaced with the content of the logged property "Message".
We can work around this by making sure we don't use "Message" as a logging property.
But. in an event-driven architecture, and in such libraries, there are plenty of cases where the property name "Message" is used.
Is there any way to getaround this?
Expected behavior
Maybe being able to control what the formatted output field is named, e.g. _message
logger.LogInfo("Hello {Message}", world);

{
     "_message":  "Hello World",   //<--- the formatted output
     "MessageTemplate": "Hello {Message}",
     "Message": "World"  //<--- the logging property Message
}

Log/SelfLog output or exception with stacktrace
No response
Application or code sample, which could be used to reproduce a bug
No response
Additional context
No response
I have read the documentation

[X] I have read Common Problems section in project wiki

Hi @rogeralsing,
It seems for me that described behavior is caused by Serilog's formatting
Have u faced this issue for another sinks? I will take a look at this behavior

Never seen this in any other sink.
It is only the json output itself that is the issue. which afaik, is generated by this lib (?)
https://github.com/serilog-contrib/serilog-sinks-grafana-loki/blob/a381464898fd17fcd187986e39cec5597bdd0512/src/Serilog.Sinks.Grafana.Loki/LokiJsonTextFormatter.cs#L67-L71
Which is then overwritten by:
https://github.com/serilog-contrib/serilog-sinks-grafana-loki/blob/a381464898fd17fcd187986e39cec5597bdd0512/src/Serilog.Sinks.Grafana.Loki/LokiJsonTextFormatter.cs#L113
If there is a property name called "Message"
Or rather, there will be a Json payload with a duplicate entry of "Message" where Loki only consumes the last occurance

Thanks, seems like a mess. Will look closer at this case. Unfortunately it is hard to give a estimate, due to Russian military invasion into my country

I think this is why some other serilog formatters (like Serilog.Formatting.Compact.RenderedCompactJsonFormatter, Serilog.Formatting.Compact) use the @m, @x, @i and @t (message, exception, instance and timestamp respectively) for the internal values.

Fixed in v7.1.1


Liquibase throws unchecked exception in afterPropertiesSet() since 4.25 (introduced by #4584)

Search first

[x] I searched and no similar issues were found

Description
We're calling SpringLiquibase.afterPropertiesSet() by ourselves in a multi tenancy application. For whatever reason we had mismatching changeset checksums in a tenant database. Before 4.25, a LiquibaseException has been thrown in that case. Since 4.25 an UnexpectedLiquibaseException is thrown instead, which is a breaking change in my point of view. Our code is catching LiquibaseException and is now not able to handle that problem properly.
Steps To Reproduce

write a small Spring Boot application that uses Liquibase
Create arbitrary changelog with some changesets
Write a component calling SpringLiquibase.afterPropertiesSet() to let Liquibase do its work
start application
manually change one or more of the generated checksums within the changelog table
restart application, exception due to mismatch will not be caught

Expected/Desired Behavior
SpringLiquibase.afterPropertiesSet() should not throw an unchecked exception. It must be possible to catch a checksum mismatch exception using the signature's exception class.
Liquibase Version
4.27
Database Vendor & Version
No response
Liquibase Integration
spring boot
Liquibase Extensions
No response
OS and/or Infrastructure Type/Provider
No response
Additional Context
No response
Are you willing to submit a PR?

[ ] I'm willing to submit a PR (Thank you!)

Hi @jetip, thank you for reporting this issue. I can see that the reason for this behaviour is that, prior to PR #4584, the method afterPropertiesSet() only handled SQLExceptions, so the mismatched checksum error was being caught by the parent method.
We will be fixing this soon.
Thank you,
Tatiana

Thanks a lot for the quick response.

@jetip welcome! Just note that this is going into liquibase 4.30.0 , and not in 4.29.2 that is going t be release next week .


Fix storefront theme asset paths

1. Why is this change necessary?
The image assets from the maintenance, error-404 and wishlist-listing sections don't get copied into the bundles folder anymore. In the changelog (SW 6.5@RC) the new behavior is described but not used in this 3 sections.
2. What does this change do, exactly?
Fixes the path to the theme assets from the storefront theme.
3. Describe each step to reproduce the issue or behaviour.

Create a new Shopware 6.5 project with the production template (symfony flex)
(Add a custom theme and enable it)
Enable the maintenance mode
You can't see the maintenance image on the maintenance page

4. Please link to the relevant issues (if any).
5. Checklist

[X] I have rebased my changes to remove merge conflicts
[ ] I have written tests and verified that they fail without my change
[X] I have created a changelog file with all necessary information about my changes
[ ] I have written or adjusted the documentation according to my changes
[ ] This change has comments for package types, values, functions, and non-obvious lines of code
[X] I have read the contribution requirements and fulfil them.

 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.

Hello,
thank you for creating this pull request.
I have opened an issue on our Issue Tracker for you. See the issue link: https://issues.shopware.com/issues/NEXT-25537
Please use this issue to track the state of your pull request.

Thank you for directly providing a fix for the issue! :+1: :blue_heart:
We've merged your PR into the trunk and <IP_ADDRESS> release branch, meaning that the fix will be included in the next release in the 6.5 line, meaning either the final release or the next RC if there will be another RC release.


topics: Convert topic links to permalinks.

Commit 1: adds a new narrow operator -- "with" which expects a string operand of message_id, and returns all the messages in the same channel and topic of the operand, with the first unread message of the topic as anchor.
Commit 2: Converts #-mention of topics to permalinks.
Commit 3: Converts left sidebar topic links and Copy link to topic to permalinks.
Fixes: #21505

Self-review checklist

[x] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[x] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[x] Responsiveness and internationalization.
[x] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[x] Corner cases, error conditions, and easily imagined bugs.

Chat thread in #api design, for cross-reference:
https://chat.zulip.org/#narrow/stream/378-api-design/topic/topic.20permalinks/near/1801198

Updated narrow operator as per the api design thread --

If message is found in local cache, use it to return the message list.
If message not found in local cache, don't fetch the message_id attached to with operator recursively, but send the entire narrow to backend and to correct the operator and fetch the message list.

Addressed all the reviews.

addressed the above reviews.

Addressed reviews, added commit to convert topic #-mentions to permalinks.

Updates:

This should accept the ID as a number, not only as a string. That is, it should accept "operand":12345, not only "operand":"12345".

now accepts both string and number

removed the operator from search typeahead.
updated to make sure that in case of with operator, the "hash change" is set to false initially, and set to true, before the view is changed (because hash change triggers another activate(), affecting anchor position)

Updates:

refined the update_narrow_terms_containing_with_operator method (which corrects the narrow operator when with is present) as per the review
Added commit to use the topic permalinks in left-sidebar  topic links, and Copy topic link of topic popover
Addressed the reviews of construct-narrow.

Addressed all reviews except this, and this.

@timabbott addressed all your set of reviews.

@roanster007 if the feedback for the backend comments is addressed here we should extract them into a separate PR and try to get that merged first.

I feel like we are approach the frontend change for this incorrectly which is bringing a lot of complexity and uneasyness in trying to render the topic correctly.

Pushing some changes soon related to how we render the narrow with a with operand.

Thanks Aman, this version looks way cleaner than the previous one. I added some tests and added made some minor changes in message_view for hash change when in case the filter has changed.

(just removed the unnececessary refactor commit at the beginning)

So I think we should limit this PR to just the main server and web app logic for supporting with URLs, without having anything generate it; that's a useful merge point and the comment thread is getting too long. I've pushed a version that fixes a bunch of issues (noted above) with that one commit, and @roanster007 can you open a second PR linking to this with the other two commits?
It should be easy enough to test this logic with just writing URLs manually, and it's really important to get the logic in the one commit here right without too much distraction.
Please review the changes, fix the test_message_fetch test suite and DM me when ready for a next review.

@timabbott , I guess as per the design thread you said:

So yeah, I think this possibly doesn't need to exist in the search typeahead.

Now since it won't be a search term, do you still think it would be needed necessary to add it to is_valid_search_term as per https://github.com/zulip/zulip/pull/30678#discussion_r1663279010 ?

I think this is in good enough shape to merge it, given that it doesn't actually do anything unless one uses the actual syntax. But we need to handle the follow-ups before the 9.0 release:

#30863 and https://github.com/zulip/zulip/pull/30114#discussion_r1676557672
My question about solo with operators in https://chat.zulip.org/#narrow/stream/378-api-design/topic/topic.20permalinks/near/1887117
#30864
#30862
A #frontend thread about the semantics of replaceState https://github.com/zulip/zulip/pull/30114#discussion_r1676578290

Failing the narrow_unread node tests; I'll let you do a push to fix that and then ping me to merge.

@timabbott node tests are fixed.

I'll fix these bugs in some time.

I think I can merge this with the tweaks noted above, and then we can fix the remaining bugs with smaller follow-up PRs that are easier to review. Thanks for all the work on this so far!
I updated https://github.com/zulip/zulip/pull/30114#issuecomment-2226642678 to flag that last bug.


Why This Project Not Updated

Is there any one who can update on this. why this project not updated from last 2 years.

I have the same question

@achaosss you can go with deepface.
I don't why people start project, after gaining popularity leave that.

@achaosss you can go with deepface.
I don't why people start project, after gaining popularity leave that.

Thank you for sharing, which has opened up a new world for me

@achaosss you can go with deepface.
I don't why people start project, after gaining popularity leave that.
can you assist a link to the repo or something else.

@achaosss you can go with deepface.
I don't why people start project, after gaining popularity leave that.

can you assist with a link to the repo or something else.

https://pypi.org/project/deepface/


QUESTION: Selected Items

Hey Vakata,
Me again! The open_all did the trick. After testing the tree i noticed something and I don't know how to fix the issue. As you know i'm now using lazy loading for the children and the open_all when you check the parent when no children is loaded.
Take a look at the following screenshot: http://imgur.com/V82olGv
You will see that i have checked the header "Block R". That parent has 371 children underneath. Visually the tree says i have 3 selected. When i click the done button and use the get_bottom_selected function to get the checked values. I get all 371 records back. I have confirmed that the get_bottom_selected function is doing it and that all the nodes state -> selected value is true.
If i only check the three items under "Block R" and click done i'm getting the 3 items. Why is it when i click on the header its selecting them all? What am I doing wrong?
Thanks again!

Hi,
Sorry, but always include all the information necessary for me to help you - it is nothing personal - I believe only this week I answered more than a hundred separate questions, I am not sure I remember your use case. Also keep in mind it is best to ask how-to questions on the groups page or on stackoverflow with a jstree tag, and keep the repo issues page for things you suspect are a bug.
As for the issue - from what I can deduct you are using the search plugin with show_only_matches and are wondering why when you click the three separate children only they are selected, but clicking the parent will check everything beneath it, even non-matches? Is that it?
If so - that is the correct behavior - show_only_matches simply hides the other nodes, but they are still there. Selecting the parent will select them all - visible or not. Otherwise clicking the parent should move it in undetermined state, which will be even more confusing - there are countless use cases, where selecting only the three nodes, when the parent is clicked will be very bad UX. I get the problem, but I still believe this is the correct behavior - just think of the nodes are temporarily hidden but still there.
If this is not it, or if you have any ideas - please share.
Best regards,
Ivan


Think of the children!

I've been reading about Hobbes for days because I've been so excited about the language and it's features. But, it's been a mirage, because I develop on Windows, and this is macos/unix only. Dang. Think of the children and consider making this available on Windows, so I can bring it up to my team.

I thought that kids these days were all on macOS.  Maybe I'm just getting old?
Are there particular features you're most interested in using?  We might be able to get there soon in small steps.
I looked at porting to Windows a while back, but I'm a little out of touch with Windows build tools and common infrastructure (e.g. building LLVM with MSVC).  Also our CI tool (travis-ci) only supports Linux and macOS, though I think there must be a Windows CI option for github (especially now that Microsoft owns it).
I've done some work on an alternative back-end (replacing LLVM) which is implemented here in a header-only lib in includes/hobbes/mc/ and I have confirmed that bit works on Windows (x86_64).  I could port hobbes to that back-end, which would make it much more lightweight (LLVM is a heavy dependency) and also it'd work on Windows.
I've been thinking about splitting those header-only bits into a different project, which would make them easier to use (and also easier to get parts working on Windows one by one).

"I thought that kids these days were all on macOS."
Only the rich kids.
"Are there particular features you're most interested in using?"
For my team's usecase, we maintain a bunch of web-services provided by the company. These 'front-end' web-services contact  backends services to actually fetch the data. In order to get the data, we have to look at all kinds of rules and entitlements to determine if the client is able to access this data, and we have to return the correct version of the data, and we need to log info about the request/response, and it needs to be speedy, etc.
Hobbes sounds like it could help us deal with the complexity of all of this in an elegant way.
Thanks for considering it!

Interesting, that does sound similar to some of our use-cases.  The data recording bits might be easier to isolate and get working on Windows independently.  That's why I was considering splitting those parts out into an independent (lighter weight) library.
For low-latency evaluation of rules like you describe, we've been using large pattern match tables.  That requires the whole compiler, so would need the whole thing translated.
Do you have experience doing automated builds on Windows?  Maybe you have some advice to offer in terms of how I might set this up?  If I could set something up to reliably build hobbes on Windows, I'd be happy to hack at the code to get it to work.

Do you have experience doing automated builds on Windows?
I'm afraid not. Our automated builds are Linux only.

Darn, so we are in the same boat then.
Are your request processors on Windows?  How do you develop that part of your infra (if not with automated builds)?
I’m just trying to understand where hobbes would fit here exactly.  Do you want to produce files from Windows?  Maybe just talk over the network with a hobbes-enabled process on a Linux host?  Or actually run queries on Windows hosts?

We develop on Windows, on Visual Studio, and deploy to production on Linux.

I did attempt to port Hobbes to Windows a while ago and ran into some obstacles:

Some of the code uses gcc specific preprocessor macros, which I couldn't get Microsofts compiler to accept. This might be less of an issue now, because clang ist optionally available.
Most of the used posix headers and functions could be easily ported since Windows also supports them with slight adjustments.
I adjusted the build system to produce separate libraries for each of the subdirectories in lib/hobbes/, that had the advantage that some of the less portable ones (events, db, rpc) did not need to be ported immediately.
Some of the platform specific code can be replaced by corresponding abstractions in LLVM on which Hobbes depends anyways.

Thanks for going to all of that trouble and reporting back!
Good to know about circleci, I wasn't aware of that one.  I did find a different service that offered Windows builds when I looked into this at one point but didn't get far enough to try it.
The macro set you highlighted is pretty important, although we could get rid of it if C++ ever supports static type reflection.
I found this comment from somebody else trying to reconcile gcc's handling of variadic macros with VC++, situation looks pretty grim:
https://stackoverflow.com/questions/9183993/msvc-variadic-macro-expansion


v0.5.1 npm tarball Contains An Extra cachebust-backup.js in the tasks folder

The tarball provided at http://registry.npmjs.org/grunt-cache-bust/-/grunt-cache-bust-0.5.1.tgz contains an extra file in the tasks folder.

Thanks for the heads up


Want to add new title to Ecommerce Sneaker Website under GSSOC'23

Describe the Feature you want to end
A attractive title to the website
Expected behavior
will make the website more attractive and also gain popularity.
Screenshots (optional)

Additional context (optional )

I would like to add a new attractive title to the website.

completed


Add Feature Issue Template

I mainly create "feature" issues which is a blanket that covers all issues not related to regressions/bugs.

https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/configuring-issue-templates-for-your-repository
GitHub is actually recommending setup via a UI so I just did that. I still think the whole .github/ directory in this repo should be copied for new projects and contain these templates.

https://docs.github.com/en/free-pro-team@latest/github/building-a-strong-community/configuring-issue-templates-for-your-repository
GitHub is actually recommending setup via a UI so I just did that. I still think the whole .github/ directory in this repo should be copied for new projects and contain these templates.


Loading issue for Angular2Esri4Module module

when I use ng serve,it will get an error
10%building modules 2/2 modules 0 activeError: Angular2Esri4Module is not an NgModule,
and then it stuck at 70%
70% building modules 695/695 modules 0 active
but if I put Angular2Esri4Module in the declarations a moment,
after ng serve run,then put Angular2Esri4Module back to  imports,
it works normally.
How do I change my code ?or it's about package ?
D:\Angular2\app_test>ng --version
angular-cli: 1.0.0-beta.22
node: 6.9.2
os: win32 x64
my package.json
 "@angular/common": "2.2.3",
  "@angular/compiler": "2.2.3",
 "@angular/core": "2.2.3",
"@angular/forms": "2.2.3",
"@angular/http": "2.2.3",
"@angular/platform-browser": "2.2.3",
"@angular/platform-browser-dynamic": "2.2.3",
"@angular/router": "3.2.3",
"@ngtools/webpack": "1.1.9",
"angular2-esri4-components": "^0.3.0",
"core-js": "^2.4.1",
"rxjs": "5.0.0-beta.12",
"ts-helpers": "^1.1.1",
"zone.js": "^0.6.23"

@HuChaoyong Thanks for raising the issue!  I'll take a look at this on my end and let you know what I find.

@HuChaoyong It appears to me right now that there is something in the angular-cli that is causing this to happen.  I'm continuing to look into better options but what I have for you right now are:

this issue is not happening esri-angular-cli-example which is using angular-cli 1.0.0-beta.19-3.  If you downgrade your angular-cli to this version the issues should go away.
I have tested this on a project using angular-cli 1.0.0-beta.24.  The ERROR in Angular2Esri4Module is not an NgModule is still there but the build process completes and everything functions correctly.  Upgrading the angular-cli to this version could put you in a better position.

One of the above options is the best I have at the moment.  There are a number of issues open on angular-cli surrounding similar error messages so I will monitor what happens over there. I will be sure to update this thread when I find a better solution.

@kgs916 thanks, now I update angular-cli to beta.24 ,situation is that  you said ,
but I find something interesting ,I use 'ng serve ' for my old project which is created by angular-cli beta.22 ,
it doesn't get error ! I don't know what happen.
oh,I find two issues in project, I forget tell you last time.

If I don't import EsriLoaderService to app.module.ts and put it in providers, it will get a error
AppComponent - inline template:0:0 caused by: No provider for EsriLoaderService! on the html.
In map.component.ts , If don't give a css class like .map{ height: 500px;} for template,
template like
<div class="map">
 <esri4-map
[mapProperties]="mapProperties"
[mapViewProperties]="mapViewProperties"
  (mapInit)="onMapInit($event)">
</esri4-map>
</div>,
the map can't display in the html.(i.e. no error for this )

@HuChaoyong Thanks for giving more feedback.  My responses are below.

If all you are doing is loading a map using the esri4-map component from the angular2-esri4-components package then you should not need to include EsriLoaderService as a provider for your module.  You need to include EsriLoaderService as a provider in your module if you plan to load any other ESRI modules into your application. angular2-esri4-components does not expose this service globally.

I'm not sure there is much that I can do about validating the CSS on the template.  However, I did not include any CSS in the examples in the README.  I will go ahead and include some CSS as it sounds like that would be helpful.

@HuChaoyong You mentioned that you have a project that was originally created with beta.22 of the angular-cli and is not getting the error after upgrading the CLI.  Could you provide me with the list of dependencies in the package.json from that project?

@kgs916  I'm sorry about that. I tested my project many times just now, but I found I can't back to that situation.might be I misread at three days ago.I'm really sorry about that.

No problem, @HuChaoyong.  Thanks for trying!

@HuChaoyong I have corrected this issue in v0.4.1 of this library.  It required using the @angular/compiler-cli to transpile the TS rather than using tsc.  I'm going to close this issue now.  Please let me know if you continue to encounter the issue and I can reopen this.

@kgs916 , no problem.


Wayland support

This app crashed on gnome wayland session:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/Xlib/xauth.py", line 42, in __init__
    raw = open(filename, 'rb').read()
FileNotFoundError: [Errno 2] No such file or directory: '/home/oleg/.Xauthority'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/emoji-keyboard", line 15, in <module>
    from emoji_keyboard import emoji_lib
  File "/usr/lib/python3.5/dist-packages/emoji_keyboard/emoji_lib.py", line 32, in <module>
    local_display = display.Display()
  File "/usr/lib/python3/dist-packages/Xlib/display.py", line 80, in __init__
    self.display = _BaseDisplay(display)
  File "/usr/lib/python3/dist-packages/Xlib/display.py", line 62, in __init__
    display.Display.__init__(*(self, ) + args, **keys)
  File "/usr/lib/python3/dist-packages/Xlib/protocol/display.py", line 61, in __init__
    name, host, displayno)
  File "/usr/lib/python3/dist-packages/Xlib/support/connect.py", line 93, in get_auth
    return getattr(mod, modname).get_auth(sock, dname, host, dno)
  File "/usr/lib/python3/dist-packages/Xlib/support/unix_connect.py", line 116, in new_get_auth
    au = xauth.Xauthority()
  File "/usr/lib/python3/dist-packages/Xlib/xauth.py", line 44, in __init__
    raise error.XauthError('~/.Xauthority: %s' % err)
Xlib.error.XauthError: ~/.Xauthority: [Errno 2] No such file or directory: '/home/oleg/.Xauthority'

There's no plans to add wayland support, at least for now, as emoji-keyboard depends heavily on X server.

Ok, so I have removed explicit dependencies on X. This should run at least on xwayland, at least in theory.
Can't test myself, as I can't get wayland to run at all.

Wayland is tested and mostly supported since version 2.3.0.
Since gnome under wayland doesn't respect no-focus property keyboard window is hidden for a sec after every selection.
Also, window moving doesn't work (at least under gnome on wayland) so where the keyboard will reappear depends solely on the window manager.
Search fully works as intended, although where the window will appear is, again, out of my control.
Check the README for installation instructions , as installation under wayland requires extra steps.


Screenshot description

Allows description for screenshots

@lsemesky - Validation added. Please review

:+1:

@mleeBoeing Tiff put the following comments on the Jira ticket:
Go to Quick View Modal
Tab through til you get to the OverView Tab screenshot tab, tab through til it comes back to the Overview Tab content
RESULTS - It reads through the Large/Small Banner and icons which do not display on the screen.  Then reads the newly added screenshot description like it should
EXPECTED RESULTS - It should only read the newly added screenshot description.


BUG-47575 Eliminate sonar blocker from 1.1 codebase

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/1792/


test: Increase btrfs loopback device size to 128MB

With btrfs-prog 4.17 as shipped with Alpine 3.8 the btrfs tests
fail with:
ERROR: '/dev/loop1' is too small to make a usable filesystem
ERROR: minimum size for each btrfs device is 114294784
btrfs-prog commit 997f9977c243 ("btrfs-progs: mkfs: Prevent
temporary system chunk to use space in reserved 1M range")
changed the code to compute the minimum size for a btrfs size
and is the likely reason for this error.
Increase the size of the loop back device to 128MB for
the btrfs test.
With this fix, the containerd tests pass on Alpine 3.8,
tested in LinuxKit with kernel 4.14.53.
fixes #2447
Signed-off-by: Rolf Neugebauer<EMAIL_ADDRESS>

If accepted, it would be good to cherry-pick this into 1.1. In LinuxKit we track the containerd releases and run the containerd tests on every PR (including kernel updates). I had to disable this LinuxKit test with the update to Alpine 3.8.

Codecov Report

Merging #2448 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2448   +/-   ##
=======================================
  Coverage   45.01%   45.01%
=======================================
  Files          92       92
  Lines        9414     9414
=======================================
  Hits         4238     4238
  Misses       4493     4493
  Partials      683      683

Flag
Coverage Δ

#linux
49.24% <ø> (ø)
:arrow_up:

#windows
41.3% <ø> (ø)
:arrow_up:

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 b416337...6519204. Read the comment docs.

LGTM


💸RICH 💎QUEEN 🌛→}+93I_🐨5791🍮O9O →}} (❥☂❥) 💯'CALL 🎀''GIRLS 🐣DEHRADUN ⚓RUSSIAN 𝓔𝓼𝓬𝓸𝓻𝓽 𝓢𝓮𝓻𝓿𝓲𝓬𝓮🚀🐣DEHRADUN

In this season of cold and fun here at High-End Dehradun Call Girls @Cath @machty  : - ☛ ☎ 93I57*9IO90 ☎ ☚, you will never get disappoint. As we always take proper care of fruitful relations between our Dehradun Escorts and Clients.
We believe in providing genuine call girls in Dehradun to each and every single client who takes aur services. We have the best adult services providing Escorts In Dehradun, who will make your stay here at Call Girls In Dehradun a lifetime experience.
💸RICH 💎QUEEN 🌛→}+93I_🐨5791🍮O9O →}} (❥☂❥) 💯'CALL 🎀''GIRLS 🐣DEHRADUN ⚓RUSSIAN 𝓔𝓼𝓬𝓸𝓻𝓽 𝓢𝓮𝓻𝓿𝓲𝓬𝓮🚀🐣DEHRADUN #27588
You just have to contact us at @eric Just Book ✍ ((☛ 📱 93157=91090)) 24*7 , hassle free as our verified call girls Dehradun are the gems you were dreaming for. You can easily find us at our website or our can visit our  Dehradun Escorts Service providing agency at Mussoorie Road , Rajpur Road Dehradun.

call girls in dehradun uttarakhand .pdf

In this season of cold and fun here at High-End Dehradun Call Girls @Cath @machty  : - ☛ ☎ 93I57*9IO90 ☎ ☚, you will never get disappoint. As we always take proper care of fruitful relations between our Dehradun Escorts and Clients.
We believe in providing genuine call girls in Dehradun to each and every single client who takes aur services. We have the best adult services providing Escorts In Dehradun, who will make your stay here at Call Girls In Dehradun a lifetime experience.
💸RICH 💎QUEEN 🌛→}+93I_🐨5791🍮O9O →}} (❥☂❥) 💯'CALL 🎀''GIRLS 🐣DEHRADUN ⚓RUSSIAN 𝓔𝓼𝓬𝓸𝓻𝓽 𝓢𝓮𝓻𝓿𝓲𝓬𝓮🚀🐣DEHRADUN #27588
You just have to contact us at @eric Just Book ✍ ((☛ 📱 93157=91090)) 24*7 , hassle free as our verified call girls Dehradun are the gems you were dreaming for. You can easily find us at our website or our can visit our  Dehradun Escorts Service providing agency at Mussoorie Road , Rajpur Road Dehradun.

call girls in dehradun uttarakhand .pdf


Check whatever any GUI element was just clicked

I'm trying to create a small game editor.
One of the features I want to add is the ability to select any game object on the screen (by clicking) and show related to that entity UI staff. Additionally, if the user clicks on empty space (no game object nor UI element) on the screen, the selection box and entity related UI elements disappear.
The issue is that it's not easy to distinguish a click on UI element and a click on empty space.
It's possible to create some kind of a list of all UI elements rectangles and validation does the current click intersects with any of them.
Another solution might be to create a texture with 8-bit int pixel format and fill it with all UI elements rectangles on the screen and check is the position of the mouse already occupied by some UI element.
But these solutions require addition coding, rather then using something already out of the box.
Is there a way in Raygui to check is any UI element just was clicked?
Also, I tired to look at guiControlExclusiveRec and guiControlExclusiveMode but it seems that they are for a bit different purpose and functions like GuiButton do not change their state.

@VladPavliuk I'm afraid it would imply a redesign of raygui and keep a internal list of rectangles, it goes agains the stateless nature of the library. I'm afraid the easiest approach is do that Rectangle management and tracking at user side, actually that's how I do it on my tools.

@raysan5 got it, thanks for the answer!


Session data not available

Hello,
I tried to update the auth0 plugin for ember simple auth 1.0 and I had it working fine yesterday but somehow have managed to break it so the session data is not available. I was hoping somebody could take a look at my example app.
Example: https://github.com/corbinu/hello-safe-world
Plugin: https://github.com/corbinu/auth0-ember-simple-auth
I have setup a test app and credentials I will remove once I figure this out. Login is:
Username<EMAIL_ADDRESS>Password: test123

NVM apparently it is now in "session.data.authenticated" instead of "session.secure" like it was before


Trouble in create-react-app in my local environment

MacBook-Pro ~ % npx create-react-app my-app
Creating a new React app in /Users/Durai/my-app.
Installing packages. This might take a couple of minutes.
Installing react, react-dom, and react-scripts with cra-template...
npm ERR! code EEXIST
npm ERR! syscall mkdir
npm ERR! path /Users/Durai/.npm/_cacache/content-v2/sha512/6d/ff
npm ERR! errno EEXIST
npm ERR! Invalid response body while trying to fetch https://registry.npmjs.org/scheduler: EACCES: permission denied, mkdir '/Users/Durai/.npm/_cacache/content-v2/sha512/6d/ff'
npm ERR! File exists: /Users/Durai/.npm/_cacache/content-v2/sha512/6d/ff
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.
npm ERR! A complete log of this run can be found in: /Users/Durai/.npm/_logs/2024-01-13T12_30_16_019Z-debug-0.log
Aborting installation.
npm install --no-audit --save --save-exact --loglevel error react react-dom react-scripts cra-template has failed.

Hello,
Did you try the suggested solutions of following link:
https://stackoverflow.com/questions/64870344/getting-trouble-to-create-a-new-react-app

First of all, ensure that npm registry is properly set.
You can check the current registry by using the following command: >>   npm config get registry
Typically you would want to set your npm registry to official npm registry using:>>
npm config set registry https://registry.npmjs.org/

Problem resolved with sudo code. Thankyou.

Hi, can you help me with the solution you have used. im getting the same issue in my mac

Hi, can you help me with the solution you have used. im getting the same issue in my mac

You need to put 'sudo' before the command line.
For example: sudo npx create-react-app your-app
Then, Enter your machine user login password for giving  'EACCES: permission' to mkdir. Then you can successfully create your react app. This is one of the easiest way and there are other ways to do the same. Make your user profile as admin.