text:
affected/package: xml/encoding

What version of Go are you using (go version)?
1.19.5
Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
windows/amd64
What did you do?
After running the snippet "https://go.dev/play/p/r7BVXxvAygX" on the input data
y
I get the output data generated by using the Encoder.EncodeToken
y
that is non-well-formed XML with a duplicated attribute name xmlns.
What did you expect to see?
y
What did you see instead?
y
Please fix.

Duplicate of #42807

authors: larhun seankhliao


text:
affected/package: golang/playground

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

$ go version 1.19.5

Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"

What did you do?
Try to launch golang/playground locally, with instruction from https://github.com/golang/playground
What did you expect to see?
Working playground
What did you see instead?
When Run button pressed - it's web interface writes
Error communicating with remote server.
Program exited.

In terminal log where is following problem:
Listening on :8080 ...
2023/02/07 05:30:40 http: panic serving 172.17.0.1:50798: no SANDBOX_BACKEND_URL environment and no default defined for project ""
goroutine 41 [running]:
net/http.(*conn).serve.func1()
	/usr/local/go/src/net/http/server.go:1850 +0xbf
panic({0xcfbfc0, 0xc0001be2d0})
	/usr/local/go/src/runtime/panic.go:890 +0x262
main.sandboxBackendURL()
	/go/src/playground/sandbox.go:569 +0xbe
main.sandboxRun({0x11b1a00, 0xc000114660}, {0xc00004ac80, 0x1c}, {0x0, 0x0})
	/go/src/playground/sandbox.go:497 +0x19c

when try make runlocal it's not working too, but with another message
Listening on :8080 ...
cmdFunc error: POST "http://sandbox_dev.sandnet/run": Post "http://sandbox_dev.sandnet/run": dial tcp: lookup sandbox_dev.sandnet: no such host

No idea how to launch it locally....

What did you do?

What were the commands that you ran?

Hi @bcmills,
I'm having the same issue, and here's the command I ran:
docker run --name=goplay -p 8181:8080 golang/playground

Finally used https://github.com/x1unix/go-playground which ran smoothly.

source: gharchive/issue

authors: bcmills comdiv essodjolo

repo: golang/go

license_type: permissive

license_source: github-api


text:
cmd/link: slice bounds out of range

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

$ go version
go version go1.21.0 darwin/amd64

Does this issue reproduce with the latest release?
yes
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/Users//Library/Caches/go-build'
GOENV='/Users//Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users//go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users//go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/Cellar/go/1.21.0/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/Cellar/go/1.21.0/libexec/pkg/tool/darwin_amd64'
GOVCS=''
GOVERSION='go1.21.0'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users//code///go.mod'
GOWORK='/Users//code//go.work'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/hy/sxcwypzn0h9bg08bpjz789y00000gn/T/go-build2316893392=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?
cd project
go run .

The same thing happens with go build ..
What did you expect to see?
My program running the same way it did on 1.20
What did you see instead?
# gitlab.com/<org>/<repo>/<project>
panic: runtime error: slice bounds out of range [74:69]

goroutine 1 [running]:
cmd/link/internal/ld.typeSymbolMangle({0x49ac657b, 0x4f})
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/lib.go:1012 +0x379
cmd/link/internal/ld.(*Link).mangleTypeSym(0xc000110000)
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/lib.go:959 +0xb9
cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0xc0000ae2e9, 0x1, 0x1}, ...})
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/main.go:308 +0x124b
main.main()
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/main.go:72 +0xdfb

I have confirmed that a simple hello world program does work so there must be something specific to the code or project environment.
I searched for the same issue and found https://github.com/golang/go/issues/61060 but this seemed too different to lump in with that, and it's happening on the latest release.

Are you able to provide more information on how this panic can be reproduced? cd project; go run . doesn't have enough context to investigate this issue.

I agree, but it's a large project with too much code to share.  Here are some extra details.  Let me know what other information I can provide.
This is the build commands (not all of them) from right before the panic.
go build -x .
...
EOF
mkdir -p $WORK/b001/exe/
cd .
/usr/local/Cellar/go/1.21.0/libexec/pkg/tool/darwin_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -X=runtime.godebugDefault=panicnil=1 -buildmode=exe -buildid=SD7wguQIlnr-RgQWclwr/Ppl_IAU-mt3aUHyZlWNE/lWXWOjpK5ruyWZBONLpe/SD7wguQIlnr-RgQWclwr -extld=cc /Users/<me>/Library/Caches/go-build/92/920429ab911f6e21f24f38184d90a4003b59918063e47f930367455dd8730926-d
# gitlab.com/<org>/<repo>/<project>
panic: runtime error: slice bounds out of range [74:69]

goroutine 1 [running]:
cmd/link/internal/ld.typeSymbolMangle({0x49b4589c, 0x4f})
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/lib.go:1012 +0x379
cmd/link/internal/ld.(*Link).mangleTypeSym(0xc000158000)
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/lib.go:959 +0xb9
cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0xc0000124a9, 0x1, 0x1}, ...})
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/main.go:308 +0x124b
main.main()
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/main.go:72 +0xdfb

This is the call graph dumped (not the whole thing) from right before the panic.
go build -ldflags="-c" .
...
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1 calls runtime.panicIndex
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1 calls runtime.panicIndex
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1 calls runtime.gopanic
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1 calls runtime.deferreturn
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1.2 calls golang.org/x/sync/semaphore.(*Weighted).Release
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1.2 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1.1 calls sync.(*Mutex).Unlock
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func1.1 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func2 calls sync.(*Mutex).Unlock
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).TryAcquire.func2 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.newobject
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.gcWriteBarrier1
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.gcWriteBarrier1
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls sync.(*Mutex).lockSlow
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls sync.(*Mutex).lockSlow
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.gcWriteBarrier2
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls sync.(*Mutex).unlockSlow
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.selectgo
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).releaseAcquiredResource
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.gcWriteBarrier2
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.gcWriteBarrier1
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls sync.(*WaitGroup).Add
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls golang.org/x/sync/semaphore.(*Weighted).Release
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls sync.(*Mutex).unlockSlow
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.selectgo
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.panicSliceAcap
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.panicIndex
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.panicIndex
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.gopanic
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).initResourceValue.func1 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).acquire.func1 calls sync.(*Mutex).Unlock
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).acquire.func1 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Stat.func1 calls sync.(*Mutex).Unlock
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Stat.func1 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Close.func3 calls github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).destructResourceValue
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Close.func3 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Close.func2 calls sync.(*Mutex).Unlock
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Close.func2 calls runtime.morestack
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Close.func1 calls sync.(*WaitGroup).Wait
github.com/jackc/puddle/v2.(*Pool[go.shape.*uint8]).Close.func1 calls runtime.morestack
panic: runtime error: slice bounds out of range [74:69]

goroutine 1 [running]:
cmd/link/internal/ld.typeSymbolMangle({0x49b0589c, 0x4f})
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/lib.go:1012 +0x379
cmd/link/internal/ld.(*Link).mangleTypeSym(0xc000158000)
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/lib.go:959 +0xb9
cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0xc0000124a9, 0x1, 0x1}, ...})
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/internal/ld/main.go:308 +0x124b
main.main()
        /usr/local/Cellar/go/1.21.0/libexec/src/cmd/link/main.go:72 +0xdfb

go.mod:
module <repo>/<project>

go 1.20

require (
	github.com/aws/aws-lambda-go v1.26.0
	github.com/dustin/go-humanize v1.0.0
	github.com/go-ozzo/ozzo-validation/v4 v4.3.0
	github.com/google/uuid v1.3.0
	github.com/gorilla/websocket v1.5.0
	github.com/grpc-ecosystem/go-grpc-middleware v1.3.0
	github.com/improbable-eng/grpc-web v0.13.0
	github.com/jackc/pgx/v5 v5.4.2
	github.com/jackc/tern/v2 v2.1.1
	github.com/mitchellh/mapstructure v1.5.0
	github.com/patrickmn/go-cache v2.1.0+incompatible
	github.com/rs/cors v1.8.0
	github.com/spf13/viper v1.15.0
	github.com/stretchr/testify v1.8.4
	github.com/tidwall/gjson v1.14.4
	gitlab.com/speedscale/speedscale/analyzer v0.0.0-00010101000000-000000000000
	gitlab.com/speedscale/speedscale/lib v0.0.0-00010101000000-000000000000
	go.einride.tech/aip v0.61.0
	go.uber.org/zap v1.24.0
	golang.org/x/net v0.10.0
	golang.org/x/sync v0.1.0
	google.golang.org/grpc v1.56.2
	google.golang.org/protobuf v1.31.0
	k8s.io/api v0.26.3
	k8s.io/apimachinery v0.26.3
	k8s.io/client-go v0.25.0
	sigs.k8s.io/controller-runtime v0.13.1
)

require (
	cloud.google.com/go/compute v1.20.1 // indirect
	cloud.google.com/go/compute/metadata v0.2.3 // indirect
	github.com/Azure/go-autorest v14.2.0+incompatible // indirect
	github.com/Azure/go-autorest/autorest v0.11.27 // indirect
	github.com/Azure/go-autorest/autorest/adal v0.9.20 // indirect
	github.com/Azure/go-autorest/autorest/date v0.3.0 // indirect
	github.com/Azure/go-autorest/logger v0.2.1 // indirect
	github.com/Azure/go-autorest/tracing v0.6.0 // indirect
	github.com/DataDog/sketches-go v1.4.1 // indirect
	github.com/Jeffail/gabs/v2 v2.6.1 // indirect
	github.com/Masterminds/goutils v1.1.1 // indirect
	github.com/Masterminds/semver/v3 v3.2.0 // indirect
	github.com/Masterminds/sprig/v3 v3.2.3 // indirect
	github.com/Masterminds/squirrel v1.5.3 // indirect
	github.com/XiaoMi/pegasus-go-client v0.0.0-20210427083443-f3b6b08bc4c2 // indirect
	github.com/allegro/bigcache/v2 v2.2.5 // indirect
	github.com/antchfx/xmlquery v1.3.9 // indirect
	github.com/antchfx/xpath v1.2.0 // indirect
	github.com/araddon/dateparse v0.0.0-20210429162001-6b43995a97de // indirect
	github.com/argoproj/argo-rollouts v1.4.1 // indirect
	github.com/asaskevich/govalidator v0.0.0-20200907205600-7a23bdc65eef // indirect
	github.com/aws/aws-sdk-go-v2 v1.17.3 // indirect
	github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream v1.4.10 // indirect
	github.com/aws/aws-sdk-go-v2/config v1.18.5 // indirect
	github.com/aws/aws-sdk-go-v2/credentials v1.13.5 // indirect
	github.com/aws/aws-sdk-go-v2/feature/ec2/imds v1.12.21 // indirect
	github.com/aws/aws-sdk-go-v2/feature/s3/manager v1.11.42 // indirect
	github.com/aws/aws-sdk-go-v2/internal/configsources v1.1.27 // indirect
	github.com/aws/aws-sdk-go-v2/internal/endpoints/v2 v2.4.21 // indirect
	github.com/aws/aws-sdk-go-v2/internal/ini v1.3.28 // indirect
	github.com/aws/aws-sdk-go-v2/internal/v4a v1.0.17 // indirect
	github.com/aws/aws-sdk-go-v2/service/cloudwatch v1.23.1 // indirect
	github.com/aws/aws-sdk-go-v2/service/firehose v1.14.22 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding v1.9.11 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/checksum v1.1.21 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/presigned-url v1.9.21 // indirect
	github.com/aws/aws-sdk-go-v2/service/internal/s3shared v1.13.20 // indirect
	github.com/aws/aws-sdk-go-v2/service/s3 v1.29.5 // indirect
	github.com/aws/aws-sdk-go-v2/service/sns v1.18.6 // indirect
	github.com/aws/aws-sdk-go-v2/service/sqs v1.19.15 // indirect
	github.com/aws/aws-sdk-go-v2/service/sso v1.11.27 // indirect
	github.com/aws/aws-sdk-go-v2/service/ssooidc v1.13.10 // indirect
	github.com/aws/aws-sdk-go-v2/service/sts v1.17.7 // indirect
	github.com/aws/smithy-go v1.13.5 // indirect
	github.com/beorn7/perks v1.0.1 // indirect
	github.com/bradfitz/gomemcache v0.0.0-20220106215444-fb4bf637b56d // indirect
	github.com/buger/jsonparser v1.1.1 // indirect
	github.com/cenkalti/backoff/v4 v4.2.1 // indirect
	github.com/cespare/xxhash/v2 v2.2.0 // indirect
	github.com/clbanning/mxj v1.8.4 // indirect
	github.com/clbanning/mxj/v2 v2.3.2 // indirect
	github.com/coreos/go-oidc v2.1.0+incompatible // indirect
	github.com/davecgh/go-spew v1.1.1 // indirect
	github.com/desertbit/timer v0.0.0-20180107155436-c41aec40b27f // indirect
	github.com/dgryski/go-rendezvous v0.0.0-20200823014737-9f7001d12a5f // indirect
	github.com/eko/gocache/v3 v3.1.1 // indirect
	github.com/emicklei/go-restful/v3 v3.8.0 // indirect
	github.com/evanphx/json-patch v5.6.0+incompatible // indirect
	github.com/evanphx/json-patch/v5 v5.6.0 // indirect
	github.com/fsnotify/fsnotify v1.6.0 // indirect
	github.com/ghodss/yaml v1.0.1-0.20190212211648-25d852aebe32 // indirect
	github.com/go-errors/errors v1.4.2 // indirect
	github.com/go-logr/logr v1.2.3 // indirect
	github.com/go-openapi/jsonpointer v0.19.5 // indirect
	github.com/go-openapi/jsonreference v0.20.0 // indirect
	github.com/go-openapi/swag v0.21.1 // indirect
	github.com/go-playground/locales v0.14.1 // indirect
	github.com/go-playground/universal-translator v0.18.1 // indirect
	github.com/go-playground/validator/v10 v10.12.0 // indirect
	github.com/go-redis/redis/v8 v8.11.5 // indirect
	github.com/go-stack/stack v1.8.0 // indirect
	github.com/gogo/protobuf v1.3.2 // indirect
	github.com/golang-jwt/jwt/v4 v4.4.2 // indirect
	github.com/golang/groupcache v0.0.0-20210331224755-41bb18bfe9da // indirect
	github.com/golang/protobuf v1.5.3 // indirect
	github.com/gomodule/redigo v1.8.5 // indirect
	github.com/google/gnostic v0.6.9 // indirect
	github.com/google/go-cmp v0.5.9 // indirect
	github.com/google/gofuzz v1.2.0 // indirect
	github.com/google/shlex v0.0.0-20191202100458-e7afc7fbc510 // indirect
	github.com/hashicorp/go-immutable-radix v1.3.1 // indirect
	github.com/hashicorp/go-memdb v1.3.2 // indirect
	github.com/hashicorp/golang-lru v0.5.4 // indirect
	github.com/hashicorp/hcl v1.0.0 // indirect
	github.com/huandu/xstrings v1.4.0 // indirect
	github.com/imdario/mergo v0.3.13 // indirect
	github.com/jackc/chunkreader/v2 v2.0.1 // indirect
	github.com/jackc/pgio v1.0.0 // indirect
	github.com/jackc/pgpassfile v1.0.0 // indirect
	github.com/jackc/pgproto3/v2 v2.3.1 // indirect
	github.com/jackc/pgservicefile v0.0.0-20221227161230-091c0ba34f0a // indirect
	github.com/jackc/puddle/v2 v2.2.0 // indirect
	github.com/jaswdr/faker v1.4.2 // indirect
	github.com/jmespath/go-jmespath v0.4.0 // indirect
	github.com/josharian/intern v1.0.0 // indirect
	github.com/json-iterator/go v1.1.12 // indirect
	github.com/klauspost/compress v1.16.5 // indirect
	github.com/klauspost/pgzip v1.2.5 // indirect
	github.com/lann/builder v0.0.0-20180802200727-47ae307949d0 // indirect
	github.com/lann/ps v0.0.0-20150810152359-62de8c46ede0 // indirect
	github.com/leodido/go-urn v1.2.2 // indirect
	github.com/magiconair/properties v1.8.7 // indirect
	github.com/mailru/easyjson v0.7.7 // indirect
	github.com/mattn/go-sqlite3 v1.14.14 // indirect
	github.com/matttproud/golang_protobuf_extensions v1.0.4 // indirect
	github.com/mitchellh/copystructure v1.2.0 // indirect
	github.com/mitchellh/reflectwalk v1.0.2 // indirect
	github.com/moby/spdystream v0.2.0 // indirect
	github.com/modern-go/concurrent v0.0.0-20180306012644-bacd9c7ef1dd // indirect
	github.com/modern-go/reflect2 v1.0.2 // indirect
	github.com/monochromegane/go-gitignore v0.0.0-20200626010858-205db1a8cc00 // indirect
	github.com/montanaflynn/stats v0.6.6 // indirect
	github.com/munnerz/goautoneg v0.0.0-20191010083416-a7dc8b61c822 // indirect
	github.com/pegasus-kv/thrift v0.13.0 // indirect
	github.com/pelletier/go-toml/v2 v2.0.6 // indirect
	github.com/pkg/errors v0.9.1 // indirect
	github.com/pmezard/go-difflib v1.0.0 // indirect
	github.com/pquerna/cachecontrol v0.1.0 // indirect
	github.com/prometheus/client_golang v1.14.0 // indirect
	github.com/prometheus/client_model v0.3.0 // indirect
	github.com/prometheus/common v0.39.0 // indirect
	github.com/prometheus/procfs v0.8.0 // indirect
	github.com/rbretecher/go-postman-collection v0.8.0 // indirect
	github.com/sergi/go-diff v1.1.0 // indirect
	github.com/sethvargo/go-password v0.2.0 // indirect
	github.com/shopspring/decimal v1.3.1 // indirect
	github.com/sirupsen/logrus v1.9.0 // indirect
	github.com/speedscale/amqp091-go v1.2.0-patched // indirect
	github.com/spf13/afero v1.9.3 // indirect
	github.com/spf13/cast v1.5.0 // indirect
	github.com/spf13/jwalterweatherman v1.1.0 // indirect
	github.com/spf13/pflag v1.0.5 // indirect
	github.com/subosito/gotenv v1.4.2 // indirect
	github.com/tidwall/match v1.1.1 // indirect
	github.com/tidwall/pretty v1.2.0 // indirect
	github.com/tidwall/sjson v1.2.5 // indirect
	github.com/xlab/treeprint v1.1.0 // indirect
	github.com/yudai/gojsondiff v1.0.0 // indirect
	github.com/yudai/golcs v0.0.0-20170316035057-ecda9a501e82 // indirect
	github.com/zach-klippenstein/goregen v0.0.0-20160303162051-795b5e3961ea // indirect
	go.mongodb.org/mongo-driver v1.4.6 // indirect
	go.starlark.net v0.0.0-20200306205701-8dd3e2ee1dd5 // indirect
	go.uber.org/atomic v1.9.0 // indirect
	go.uber.org/multierr v1.8.0 // indirect
	golang.org/x/crypto v0.10.0 // indirect
	golang.org/x/exp v0.0.0-20220722155223-a9213eeb770e // indirect
	golang.org/x/oauth2 v0.8.0 // indirect
	golang.org/x/sys v0.9.0 // indirect
	golang.org/x/term v0.9.0 // indirect
	golang.org/x/text v0.10.0 // indirect
	golang.org/x/time v0.1.0 // indirect
	google.golang.org/appengine v1.6.7 // indirect
	google.golang.org/genproto/googleapis/rpc v0.0.0-20230725213213-b022f6e96895 // indirect
	gopkg.in/inf.v0 v0.9.1 // indirect
	gopkg.in/ini.v1 v1.67.0 // indirect
	gopkg.in/natefinch/lumberjack.v2 v2.0.0 // indirect
	gopkg.in/square/go-jose.v2 v2.5.1 // indirect
	gopkg.in/tomb.v2 v2.0.0-20161208151619-d5d1b5820637 // indirect
	gopkg.in/yaml.v2 v2.4.0 // indirect
	gopkg.in/yaml.v3 v3.0.1 // indirect
	istio.io/api v0.0.0-20210915141110-a591ff3be6be // indirect
	istio.io/client-go v1.11.3 // indirect
	istio.io/gogo-genproto v0.0.0-20210113155706-4daf5697332f // indirect
	k8s.io/apiextensions-apiserver v0.25.0 // indirect
	k8s.io/cli-runtime v0.24.3 // indirect
	k8s.io/klog/v2 v2.80.1 // indirect
	k8s.io/kube-openapi v0.0.0-20221012153701-172d655c2280 // indirect
	k8s.io/kubectl v0.24.3 // indirect
	k8s.io/metrics v0.24.3 // indirect
	k8s.io/utils v0.0.0-20230313181309-38a27ef9d749 // indirect
	sigs.k8s.io/json v0.0.0-20220713155537-f223a00ba0e2 // indirect
	sigs.k8s.io/kustomize/api v0.12.1 // indirect
	sigs.k8s.io/kustomize/kyaml v0.13.9 // indirect
	sigs.k8s.io/structured-merge-diff/v4 v4.2.3 // indirect
	sigs.k8s.io/yaml v1.3.0 // indirect
)

replace gitlab.com/<repo>/<project>/lib => ../lib

That code is
        i := strings.IndexByte(name, '[')
        j := strings.LastIndexByte(name, ']')
        if j == -1 {
                j = len(name)
        }
        hash := notsha256.Sum256([]byte(name[i+1 : j]))

To have such a slice out of bounds error, the symbol name would be something like ...]...[... with unmatched brackets. I don't see why a symbol would have such a name. Maybe a non-Go symbol?
The linker code could be more defensive on that. It would be good to see an example of such symbol, though.

I've found something.  The program builds if I comment this code
// guard against invalid S3 characters
if strings.ContainsAny(id, "&$@;/:+,?\\{^}%`]\">[~<#|") {
	return fmt.Errorf("invalid")
}

Though I am unable to reproduce the error in a sample program.

Thanks. A simple reproducer is
package main

import (
	"fmt"
	"plugin"
	"strings"
)

func F(id string) error {
	if strings.ContainsAny(id, "&$@;/:+,?\\{^}%`]\">[~<#|") {
		return fmt.Errorf("invalid")
	}
	return nil
}

var X string

func main() {
	plugin.Open("XXX")
	F(X)
}

We need to use plugin (or build as a plugin) to trigger the symbol name mangling.
The offensive symbol is go:string."&$@;/:+,?\\{^}%]">[~<#|"` for the string literal. There is probably no need to mangle that symbol name as string symbols will not be in the final executable's symbol table.

Might be related, we are seeing a similar issue: https://github.com/golang/go/issues/62131

This error is very specific to the linker. It is unrelated to other index out of bounds errors outside of the linker, including  #61060 and #62131. Thanks.

@gopherbot please backport this to Go 1.21. It is a regression in 1.21 causing valid programs fail to build. Thanks.

authors: cherrymui dmitshur jimmson swtch1


text:
syscall: TestDeathSignal failed in github code space.

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

$ go version
tip

Does this issue reproduce with the latest release?
yes.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/workspaces/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/workspaces/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.22-ee788dba Sat Sep 9 01:48:44 2023 +0000'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/workspaces/go/src/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2757108754=/tmp/go-build -gno-record-gcc-switches'

What did you do?
Fork golang/go in github, see https://docs.github.com/en/codespaces/developing-in-codespaces/creating-a-codespace-for-a-repository Create a code space.
See also https://docs.github.com/en/codespaces/developing-in-codespaces/opening-an-existing-codespace Open the code space.
cd src
./all.bash
What did you expect to see?
Test passed.
What did you see instead?
death signal parent error: fork/exec /tmp/TestDeathSignal3458263251/syscall.test: permission denied
--- FAIL: TestDeathSignal (0.00s)
exec_pdeathsig_test.go:97: did not receive start from child, received "", EOF
FAIL
FAIL    syscall 1.447s

This is one of the tests that was also failing on the LUCI builders and was skipped in https://go.dev/cl/513779 (CC @dmitshur @heschi).
As I commented on that CL:

I suspect that the real problem in this case is that the deathSignalParent function hard-codes a specific UID and GID that probably don't apply in a chroot:
https://cs.opensource.google/go/go/+/master:src/syscall/exec_pdeathsig_test.go;l=111-113;drc=2ad666dea0490305bb7fd2dd6e7beb767acfd2c3
Probably the test should be changed to look up the actual UID and GID for nobody, and should skip the test if that lookup fails.

@qiulaidongfeng, want to send a CL implementing that approach?

Yes, I will send the CL after repairing the test failure according to your method.
---Original---
From: "Bryan C. @.>
Date: Tue, Sep 19, 2023 22:09 PM
To: @.>;
Cc: @.@.>;
Subject: Re: [golang/go] syscall: TestDeathSignal failed in github code space.(Issue #62719)
This is one of the tests that was also failing on the LUCI builders and was skipped in https://go.dev/cl/513779 (CC @dmitshur @heschi).
As I commented on that CL:
I suspect that the real problem in this case is that the deathSignalParent function hard-codes a specific UID and GID that probably don't apply in a chroot:
https://cs.opensource.google/go/go/+/master:src/syscall/exec_pdeathsig_test.go;l=111-113;drc=2ad666dea0490305bb7fd2dd6e7beb767acfd2c3
Probably the test should be changed to look up the actual UID and GID for nobody, and should skip the test if that lookup fails.
@qiulaidongfeng, want to send a CL implementing that approach?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

authors: bcmills qiulaidongfeng


text:
Raspberry Pi5

I'm not sure if I can be of any use to you but I have a Raspberry Pi5 already in my hands as I was part of the test group for it. If you'd like any testing done on it i'm happy to help. I did try to get things running today from your github repo but i'm still a very newbie rust user so didn't get past the
'''
Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
'''
running the examples which i believe is an error on how i built the library rather than the library itself

Thanks for the offer! I've added all the basics, but there is only so much I can do without a physical device, or access to technical documentation.
I'm not that worried about SPI, I2C, UART and PWM support as these are handled by linux devices. GPIO however, reads/writes to the registers directly through /dev/gpiomem, and with the addition of the new RP1, I don't know if anything has changed there.
The error you received likely means one of the relevant devices in the /dev/ directory isn't available, and either hasn't been configured in /boot/config.txt, or isn't available on the Pi 5. Which one is missing depends on the peripheral the example(s) were trying to access. I did just add a commit to allow the library to detect the pinctrl-bcm2712 driver, so that could've been the reason for that error as well.
Since you mentioned you're relatively new to Rust, I suggest running the examples one by one to figure out which ones work, and which ones return an error, so we can narrow down what's causing the problem. For instance, to test the GPIO status example, run cargo run --example gpio_status.

i'm not sure if /dev/gpiomem exists anymore as the new bookworm update to pios (public release due mid-october) has fully moved to libgpio

and this is what i get running gpio_status

update: just checked and yes no /dev/gpiomem BUT there is a /dev/rp1-gpiomem which i'm guessing is what we (ok you :) ) need

Hmm, I wonder if running bookworm on a Pi 4 or older will still get you a /dev/gpiomem instead of a /dev/rp1-gpiomem. The name change does make me wonder if the registers have changed significantly. Hopefully this'll become clear before the Pi 5 is released. I definitely don't want to just change the device name for the Pi 5 and hope for the best.
I think at this point the options are to wait for documentation and access to a Pi 5 at release, or consider libgpiod, assuming performance doesn't lag too far behind directly accessing the registers.

and this is what i get running gpio_status

Did you update your local rppal clone with the latest commit? Just curious if the file not found error was caused by the lack of pinctrl-bcm2712 detection or something else.

just did a git pull and get the same
ukscone@glooston:~/rppal $ git pull remote: Enumerating objects: 15, done. remote: Counting objects: 100% (15/15), done. remote: Compressing objects: 100% (2/2), done. remote: Total 10 (delta 8), reused 10 (delta 8), pack-reused 0 Unpacking objects: 100% (10/10), 2.18 KiB | 744.00 KiB/s, done. From https://github.com/golemparts/rppal    c475002..3a199de  master     -> origin/master Updating c475002..3a199de Fast-forward  src/gpio/ioctl.rs | 2 ++  src/gpio/mem.rs   | 6 +++---  2 files changed, 5 insertions(+), 3 deletions(-) ukscone@glooston:~/rppal $ cargo run --example gpio_status    Compiling rppal v0.14.1 (/home/ukscone/rppal)     Finished dev [unoptimized + debuginfo] target(s) in 1.25s      Running target/debug/examples/gpio_status Error: PermissionDenied("/dev/mem") ukscone@glooston:~/rppal $ sudo target/debug/examples/gpio_status Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" }) ukscone@glooston:~/rppal $

Thanks for all the testing so far. I think it's time to dive into https://github.com/raspberrypi/linux/pull/5618 and see what exactly has changed. Hopefully that'll give me a better picture of what I can do at this point.
My best guess is that I'm trying to look for the wrong driver name, but speculation will only get me so far 😁. I'll give that PR a read and will ping you when there's more to test. I appreciate the help!

@ukscone would you mind giving https://github.com/golemparts/gpiochip a run on your Pi 5 and paste the results? It should give you a list of all available gpiochip driver names and the number of lines, similar to this
meer@flex:~/gpiochip $ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/gpiochip`
ChipInfo { name: "gpiochip0", label: "pinctrl-bcm2711", lines: 58 }
ChipInfo { name: "gpiochip1", label: "raspberrypi-exp-gpio", lines: 8 }

We should be seeing pinctrl-bcm2712 and/or pinctrl-rp1, but I'd like to confirm.

sorry for the delay. I overslept
ukscone@glooston:~ $ git clone https://github.com/golemparts/gpiochip.git Cloning into 'gpiochip'... remote: Enumerating objects: 11, done. remote: Counting objects: 100% (11/11), done. remote: Compressing objects: 100% (10/10), done. remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0 Receiving objects: 100% (11/11), 7.41 KiB | 7.41 MiB/s, done. ukscone@glooston:~ $ cd gpiochip ukscone@glooston:~/gpiochip $ cargo run    Compiling libc v0.2.148    Compiling gpiochip v0.1.0 (/home/ukscone/gpiochip)     Finished dev [unoptimized + debuginfo] target(s) in 2.86s      Running target/debug/gpiochipChipInfo { name: "gpiochip0", label: "gpio-brcmstb@107d508500", lines: 32 } ChipInfo { name: "gpiochip1", label: "gpio-brcmstb@107d508520", lines: 4 } ChipInfo { name: "gpiochip2", label: "gpio-brcmstb@107d517c00", lines: 17 } ChipInfo { name: "gpiochip3", label: "gpio-brcmstb@107d517c20", lines: 6 } ChipInfo { name: "gpiochip4", label: "pinctrl-rp1", lines: 54 } ChipInfo { name: "gpiochip5", label: "fsm_leds", lines: 2 } ukscone@glooston:~/gpiochip $

sorry that's a mess recopying
ukscone@glooston:~ $ git clone https://github.com/golemparts/gpiochip.git
Cloning into 'gpiochip'...
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0
Receiving objects: 100% (11/11), 7.41 KiB | 7.41 MiB/s, done.
ukscone@glooston:~ $ cd gpiochip
ukscone@glooston:~/gpiochip $ cargo run
Compiling libc v0.2.148
Compiling gpiochip v0.1.0 (/home/ukscone/gpiochip)
Finished dev [unoptimized + debuginfo] target(s) in 2.86s
Running target/debug/gpiochip
ChipInfo { name: "gpiochip0", label: "gpio-brcmstb@107d508500", lines: 32 }
ChipInfo { name: "gpiochip1", label: "gpio-brcmstb@107d508520", lines: 4 }
ChipInfo { name: "gpiochip2", label: "gpio-brcmstb@107d517c00", lines: 17 }
ChipInfo { name: "gpiochip3", label: "gpio-brcmstb@107d517c20", lines: 6 }
ChipInfo { name: "gpiochip4", label: "pinctrl-rp1", lines: 54 }
ChipInfo { name: "gpiochip5", label: "fsm_leds", lines: 2 }
ukscone@glooston:~/gpiochip $

the above matches exactly what we get from libgpio's gpiodetect
ukscone@glooston:~/gpiochip $ gpiodetect
gpiochip0 [gpio-brcmstb@107d508500] (32 lines)
gpiochip1 [gpio-brcmstb@107d508520] (4 lines)
gpiochip2 [gpio-brcmstb@107d517c00] (17 lines)
gpiochip3 [gpio-brcmstb@107d517c20] (6 lines)
gpiochip4 [pinctrl-rp1] (54 lines)
gpiochip5 [fsm_leds] (2 lines)
ukscone@glooston:~/gpiochip $

Awesome. I'll have it grab pinctrl-rp1 when a Raspberry Pi 5 is detected. That should fix the File not found error message.
The next hurdle is /dev/rp1-gpiomem, although it would be nice to switch over to gpiochip completely (basically the same thing libgpiod does). I do recall looking into that before and finding some issues at the time (see https://github.com/golemparts/rppal/issues/23#issuecomment-468914674 if you're interested). However, that was 4 years ago and things may have improved. I'll have a look and see if it's ready for use now, as that would be the easiest way to support GPIO going forward.

Things seem to have improved a lot with the v2 API. Let's see if moving away from directly accessing gpiomem is an option now.

that's great. hopefully you'll be able to get everything Pi5 compatible by the time people start getting them in their paws.
i'v been slowly porting all my stuff that used python* & gpiozero to rust & rust+tauri and rppal is part of my path to a pythonfree life
*the python/pip/venv stuff on bookworm makes it a bit harder to quickly knock up a script

Great to hear rppal has been useful to you! I've only dabbled in python - my background lies in C++. When I started this project ~7 years ago (it actually started out as part of the blinkt crate) I was still relatively new to Rust, and I'm still as excited about the language as when I first heard about it.
I think we'll be okay with Pi5 support for the launch date with your help. I've reached out to Raspberry Pi to see if they have any leftover review units available (and for future device releases as well), but I haven't heard back from them yet. So for now we'll have to rely on your testing, which has been invaluable so far.

did a git pull just now just for the hell of it and tried gpio_status and that's looking much better :)
ukscone@glooston:~/rppal/target/debug/examples $ ./gpio_status
Error: PermissionDenied("/dev/mem")
ukscone@glooston:~/rppal/target/debug/examples $ sudo !!
sudo ./gpio_status
+------+-------+---+---------+---+-------+------+
| GPIO | Mode  | L |   Pin   | L | Mode  | GPIO |
+------+-------+---+----+----+---+-------+------+
|      | 3.3 V |   |  1 |  2 |   | 5 V   |      |
|    2 | IN    | 0 |  3 |  4 |   | 5 V   |      |
|    3 | IN    | 0 |  5 |  6 |   | GND   |      |
|    4 | IN    | 0 |  7 |  8 | 0 | IN    |   14 |
|      | GND   |   |  9 | 10 | 0 | IN    |   15 |
|   17 | IN    | 0 | 11 | 12 | 0 | IN    |   18 |
|   27 | IN    | 0 | 13 | 14 |   | GND   |      |
|   22 | IN    | 0 | 15 | 16 | 0 | IN    |   23 |
|      | 3.3 V |   | 17 | 18 | 0 | IN    |   24 |
|   10 | IN    | 0 | 19 | 20 |   | GND   |      |
|    9 | IN    | 0 | 21 | 22 | 0 | IN    |   25 |
|   11 | IN    | 0 | 23 | 24 | 0 | IN    |    8 |
|      | GND   |   | 25 | 26 | 0 | IN    |    7 |
|    0 | IN    | 0 | 27 | 28 | 0 | IN    |    1 |
|    5 | IN    | 0 | 29 | 30 |   | GND   |      |
|    6 | IN    | 0 | 31 | 32 | 0 | IN    |   12 |
|   13 | IN    | 0 | 33 | 34 |   | GND   |      |
|   19 | IN    | 0 | 35 | 36 | 0 | IN    |   16 |
|   26 | IN    | 0 | 37 | 38 | 0 | IN    |   20 |
|      | GND   |   | 39 | 40 | 0 | IN    |   21 |
+------+-------+---+----+----+---+-------+------+
ukscone@glooston:~/rppal/target/debug/examples $

Solved the file not found error at least 😁 . I wouldn't trust the GPIO data at the moment though, since the /dev/mem method still tries to access the registers directly using the old layout, which may have changed completely because of the RP1.

After checking out the gpiochip v2 API interface today, I've hit the same roadblocks as with v1, with the exception of pull-ups/pull-downs, which are supported now.
As far as I can tell, gpiochip isn't able to tell when a GPIO line has been set to any of the Alt functions. It shows those as Input instead. While that isn't a major issue per se, since a GPIO line configured for an alternative function technically isn't a GPIO line anymore, the problem lies with tools such as the gpio_status example, that need to be able to show the mode and pin level for each GPIO line.
When a GPIO_V2_GET_LINE_IOCTL and a subsequent GPIO_V2_LINE_GET_VALUES_IOCTL ioctl request is sent to get the pin level of such a line, gpiochip ends up changing the mode from whatever Alt function it used to have to Input. That means gpio_status simply wouldn't work anymore, because it would overwrite any configured Alt modes to Input simply by reading their levels. It's possible I missed something, so I'll be going over this in more detail tomorrow, but considering v1 had the same issue, I think this might not be solvable. I grabbed the gpiod commandline tools to compare, but they gave me the same results.
Additionally, it looks like gpiochip doesn't see pin mode changes that were made directly through the registers until a GPIO line has been accessed at least once, requiring 2 reads. I'm not sure if this issue is worth a workaround, since it only seems to affect changes that were made through /dev/gpiomem, but it's definitely a concern to think about.
It basically boils down to gpiochip only offering a subset of the register access RPPAL currently uses.
Assuming there are no easy fixes for the above, that leaves me with a few options.

Move to gpiochip, remove any support for Alt functions, and require a GPIO mode to be set before its level can be read, which means getting rid of Pin and only having InputPin, OutputPin and IoPin. Tools like gpio_status won't work anymore with RPPAL.
Wait for technical documentation and add support for /dev/rp1-gpiomem. All functionality will remain the same, but the library probably won't be Pi 5 compatible on the launch date.
Stick with gpiochip for now, remove the above-mentioned functionality, then switch back to /dev/gpiomem and /dev/rp1-gpiomem when technical documentation has been made available. I'm not a fan of removing and adding back functionality people might be relying on, but at least everything would work eventually, and RPPAL will be ready for the Pi 5. Users with older models can stick to the current release of RPPAL.

If I had a Pi 5 here I'd probably grab the pinctrl-rp1 source and work on direct register access support based on that, but it's simply too time consuming to test with our current situation.
Open to any other suggestions if you have some.

Just mulling over a 4th option, since I might be able to determine a GPIO line isn't configured as a GPIO anymore based on the name instead. For instance, GPIO 9, 10, 11 are set to Alt0 for SPI. gpiochip doesn't show the alt mode, but it does mention the appropriate functionality in the name field (SPI_MISO, SPI_MOSI, SPI_SCLK) as opposed to a GPIO line configured for GPIO having a GPIOxx name.
I could add some restrictions to what a Pin can read based on the name provided by gpiochip.

Looks like the names are hardcoded. After disabling SPI and rebooting, the names remain the same even though they're not configured for SPI anymore.

I'm not sure if it's any use but gpiozero v2 is compatible with the Pi5 so it might be worth looking in there to see if there is any info that'll give clues.
https://github.com/gpiozero/gpiozero/tree/pi5

Thanks for the link. While I'm not experienced with python, I gave it a quick look. It seems to be using lgpio under the hood to access gpiochip, which, based on the docs, has the same limitations as mentioned above - it only recognizes and works with input and output pins.

Hm... Option 5, switch to gpiochip, leave Pin as-is except for the ability to read the current pin level. That way, anyone reading the level will have to make a conscious decision to set a specific mode for the pin through into_input / into_output / into_io. No pin levels anymore for gpio_status, but it can still show input/output as reported by gpiochip, and the overall structure of the Gpio module remains mostly the same.

Btw, I've updated https://github.com/golemparts/gpiochip with the code I've been testing. If you look at src/main.rs, you'll see a commented out section that'll retrieve the GPIO pin levels. Uncommenting it causes any alt-configured pins to be changed to an inputs.

oh btw not sure if you realized that once pios (bookworm) is released libgpio and thus gpiochip (&gpiomem probably) will be the way for the gpio on the pi (all models) any other methods will go away. i think you are ok with the pi1 to pi4 but just wanted to make sure you were aware :)

Btw, I've updated https://github.com/golemparts/gpiochip with the code I've been testing. If you look at https://github.com/golemparts/gpiochip/blob/main/src/main.rs, you'll see a commented out section that'll retrieve the GPIO pin levels. Uncommenting it causes any alt-configured pins to be changed to inputs.

remote: Enumerating objects: 13, done.
remote: Counting objects: 100% (13/13), done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 9 (delta 4), reused 7 (delta 2), pack-reused 0
Unpacking objects: 100% (9/9), 5.33 KiB | 1.78 MiB/s, done.
From https://github.com/golemparts/gpiochip
0f7ec31..fcd6b6d  main       -> origin/main
Updating 0f7ec31..fcd6b6d
Fast-forward
src/ioctl.rs | 615 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------------------------
src/main.rs  |  48 ++++++++---
2 files changed, 476 insertions(+), 187 deletions(-)
ukscone@glooston:~/gpiochip $ cargo run
Compiling gpiochip v0.1.0 (/home/ukscone/gpiochip)
Finished dev [unoptimized + debuginfo] target(s) in 0.66s
Running target/debug/gpiochip
ChipInfo: "gpiochip4" "pinctrl-rp1" 54
0: ID_SD Consumer:[] Flags:[input]
1: ID_SC Consumer:[] Flags:[input]
2: PIN3 Consumer:[] Flags:[input]
3: PIN5 Consumer:[] Flags:[input]
4: PIN7 Consumer:[onewire@0] Flags:[used output open_drain]
5: PIN29 Consumer:[] Flags:[input]
6: PIN31 Consumer:[] Flags:[input]
7: PIN26 Consumer:[spi0 CS1] Flags:[used active_low output]
8: PIN24 Consumer:[spi0 CS0] Flags:[used active_low output]
9: PIN21 Consumer:[] Flags:[input]
10: PIN19 Consumer:[] Flags:[input]
11: PIN23 Consumer:[] Flags:[input]
12: PIN32 Consumer:[] Flags:[input]
13: PIN33 Consumer:[] Flags:[input]
14: PIN8 Consumer:[] Flags:[input]
15: PIN10 Consumer:[] Flags:[input]
16: PIN36 Consumer:[] Flags:[input]
17: PIN11 Consumer:[] Flags:[input]
18: PIN12 Consumer:[] Flags:[input]
19: PIN35 Consumer:[] Flags:[input]
20: PIN38 Consumer:[] Flags:[input]
21: PIN40 Consumer:[] Flags:[input]
22: PIN15 Consumer:[] Flags:[input]
23: PIN16 Consumer:[] Flags:[input]
24: PIN18 Consumer:[] Flags:[input]
25: PIN22 Consumer:[] Flags:[input]
26: PIN37 Consumer:[] Flags:[input]
27: PIN13 Consumer:[] Flags:[input]

oh btw not sure if you realized that once pios (bookworm) is released libgpio and thus gpiochip (&gpiomem probably) will be the way for the gpio on the pi (all models) any other methods will go away. i think you are ok with the pi1 to pi4 but just wanted to make sure you were aware :)

Yeah, thankfully I moved away from using sysfs years ago. I think I'll just have to switch to gpiochip for now on systems that have the v2 API available (another thing to check for. good thing bookworm is required for the Pi 5 at least), and reassess /dev/gpiomem and /dev/rp1-gpiomem at a later date. I'll have to remove some of RPPAL's functionality, but considering how widely gpiochip / libgpiod are used, at least we'll all be in the same boat. 😁

I've also come across https://github.com/raspberrypi/utils/tree/master/pinctrl after spotting Gadgetoid's fancy new CLI tool that uses its data. Unfortunately it requires sudo, so not really an option until that changes.

After sleeping on it, I think the best way forward is to make gpiochip the default interface used by the Gpio module, which means I'll have to remove the above-mentioned functionality. The existing gpiomem interface, including the removed functionality, will be put behind a feature flag, so older systems that don't have the v2 API or users that require the removed functionality are still able to use RPPAL the same way as before.
I'll let you know when the library is ready for some Pi 5 testing.

two documents have been released today that might be of use to you (disclaimer: not read them myself yet)
https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf rp1-peripheral and https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf  bcm2711 peripherals

Oh wow. I thought we weren't getting any RP1 documentation for weeks. That is going to be very helpful for adding rp1-gpiomem support. This certainly changes things. I should be able to add support for reading/writing to the registers directly based on this, which means gpiochip and its limitations won't be an issue anymore.
Would you mind checking if /dev/rp1-gpiomem has properly configured file permissions? I would expect its group to be set to gpio with read/write permissions.

ukscone@glooston:/dev $ ls -al /dev/rp1-gpiomem
crw-rw---- 1 root gpio 240, 0 Oct  6 10:41 /dev/rp1-gpiomem
ukscone@glooston:/dev $

Just to give you a quick update, I've had a busy week because of unrelated work stuff, but I should have some time over the next few days to get this up and running. I've made some initial internal changes to use a different gpiomem interface based on the Pi model, but I haven't implemented any specific functionality for the Pi 5 yet.
Based on what I found in the DTs and the documentation I think I have an accurate idea of the rp1-gpiomem layout, but misinterpretation and bugs are possible, so we should take things slow when testing this. Will ping you when it's time to run gpio_status 😁

i'll be out and about on Saturday but apart that that i'm at your beck and call :)

@ukscone I implemented all the needed functionality to work with rp1-gpiomem. The internal interface is a lot more involved compared to the old gpiomem so there's a higher chance for bugs, but we'll have to start testing to find any issues at this point since the code looks good to me.
While reading from the registers should be safe, there is a risk when changing modes / levels / bias. Values could be written to the wrong register, causing unexpected results. If you'd rather stick to only testing read operations, I completely understand.
When you have some time, you can update your local rppal repo and run cargo --run example gpio_status. Assuming you have some pins configured for I2C, SPI, as outputs, etc, you should be seeing the appropriate Alt modes or Input/Output and the pin levels in the output.
Should we run into any unsolvable issues, I'll probably ask you to dump the contents of rp1-gpiomem to a file so I can use that to do some debugging on my side. It's not perfect, but it beats having no test data at all.

heh you are not going to believe this. switched to bookworm release image rather than the beta image i had been using and the rp1-gpiomem has gone away :)
ukscone@glooston:~/rppal $ cargo run --example gpio_status
Updating crates.io index
Downloaded simple-signal v1.1.1
Downloaded lazy_static v1.4.0
Downloaded libc v0.2.149
Downloaded 3 crates (729.2 KB) in 1.00s
Compiling libc v0.2.149
Compiling lazy_static v1.4.0
Compiling rppal v0.14.1 (/home/ukscone/rppal)
Compiling simple-signal v1.1.1
Finished dev [unoptimized + debuginfo] target(s) in 6.45s
Running target/debug/examples/gpio_status
Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
smh
we now have 5 gpiomems -- gpiomem0-4
lol it doesn't rain it pours :)

Well, on the bright side, at least that matches with the bcm2712-rpi.dtsi I've been basing some of this on. gpiomem0 should contain the same stuff. I'll make the change and we can see what roadblock we run into next. 😁

Should be good to go now.

the libgpiod tool gpioinfo shows this on the release image
ukscone@glooston:~/rppal $ gpioinfo
gpiochip0 - 32 lines:
line   0:          "-"       unused   input  active-high
line   1: "2712_BOOT_CS_N" "spi10 CS0" output active-low [used]
line   2: "2712_BOOT_MISO" unused input active-high
line   3: "2712_BOOT_MOSI" unused input active-high
line   4: "2712_BOOT_SCLK" unused input active-high
line   5:          "-"       unused   input  active-high
line   6:          "-"       unused   input  active-high
line   7:          "-"       unused   input  active-high
line   8:          "-"       unused   input  active-high
line   9:          "-"       unused   input  active-high
line  10:          "-"       unused   input  active-high
line  11:          "-"       unused   input  active-high
line  12:          "-"       unused   input  active-high
line  13:          "-"       unused   input  active-high
line  14:   "PCIE_SDA"       unused   input  active-high
line  15:   "PCIE_SCL"       unused   input  active-high
line  16:          "-"       unused   input  active-high
line  17:          "-"       unused   input  active-high
line  18:          "-"       unused   input  active-high
line  19:          "-"       unused   input  active-high
line  20:   "PWR_GPIO" "pwr_button"   input   active-low [used]
line  21: "2712_G21_FS" unused input active-high
line  22:          "-"       unused   input  active-high
line  23:          "-"       unused   input  active-high
line  24:     "BT_RTS"       unused   input  active-high
line  25:     "BT_CTS"       unused   input  active-high
line  26:     "BT_TXD"       unused   input  active-high
line  27:     "BT_RXD"       unused   input  active-high
line  28:      "WL_ON"  "wl_on_reg"  output  active-high [used]
line  29:      "BT_ON"   "shutdown"  output  active-high [used]
line  30: "WIFI_SDIO_CLK" unused input active-high
line  31: "WIFI_SDIO_CMD" unused input active-high
gpiochip1 - 4 lines:
line   0: "WIFI_SDIO_D0" unused input active-high
line   1: "WIFI_SDIO_D1" unused input active-high
line   2: "WIFI_SDIO_D2" unused input active-high
line   3: "WIFI_SDIO_D3" unused input active-high
gpiochip2 - 17 lines:
line   0:    "RP1_SDA"       unused   input  active-high
line   1:    "RP1_SCL"       unused   input  active-high
line   2:    "RP1_RUN" "RP1 RUN pin" output active-high [used]
line   3: "SD_IOVDD_SEL" "vdd-sd-io" output active-high [used]
line   4:  "SD_PWR_ON" "sd_vcc_reg"  output  active-high [used]
line   5:  "SD_CDET_N"       unused   input  active-high
line   6:   "SD_FLG_N"       unused   input  active-high
line   7:          "-"       unused   input  active-high
line   8:  "2712_WAKE"       unused   input  active-high
line   9: "2712_STAT_LED" "ACT" output active-low [used]
line  10:          "-"       unused   input  active-high
line  11:          "-"       unused   input  active-high
line  12:   "PMIC_INT"       unused   input  active-high
line  13: "UART_TX_FS"       unused   input  active-high
line  14: "UART_RX_FS"       unused   input  active-high
line  15:          "-"       unused   input  active-high
line  16:          "-"       unused   input  active-high
gpiochip3 - 6 lines:
line   0:  "HDMI0_SCL"       unused   input  active-high
line   1:  "HDMI0_SDA"       unused   input  active-high
line   2:  "HDMI1_SCL"       unused   input  active-high
line   3:  "HDMI1_SDA"       unused   input  active-high
line   4:   "PMIC_SCL"       unused   input  active-high
line   5:   "PMIC_SDA"       unused   input  active-high
gpiochip4 - 54 lines:
line   0:      "ID_SD"       unused   input  active-high
line   1:      "ID_SC"       unused   input  active-high
line   2:       "PIN3"       unused   input  active-high
line   3:       "PIN5"       unused   input  active-high
line   4:       "PIN7"       unused   input  active-high
line   5:      "PIN29"       unused   input  active-high
line   6:      "PIN31"       unused   input  active-high
line   7:      "PIN26"   "spi0 CS1"  output   active-low [used]
line   8:      "PIN24"   "spi0 CS0"  output   active-low [used]
line   9:      "PIN21"       unused   input  active-high
line  10:      "PIN19"       unused   input  active-high
line  11:      "PIN23"       unused   input  active-high
line  12:      "PIN32"       unused   input  active-high
line  13:      "PIN33"       unused   input  active-high
line  14:       "PIN8"       unused   input  active-high
line  15:      "PIN10"       unused   input  active-high
line  16:      "PIN36"       unused   input  active-high
line  17:      "PIN11"       unused   input  active-high
line  18:      "PIN12"       unused   input  active-high
line  19:      "PIN35"       unused   input  active-high
line  20:      "PIN38"       unused   input  active-high
line  21:      "PIN40"       unused   input  active-high
line  22:      "PIN15"       unused   input  active-high
line  23:      "PIN16"       unused   input  active-high
line  24:      "PIN18"       unused   input  active-high
line  25:      "PIN22"       unused   input  active-high
line  26:      "PIN37"       unused   input  active-high
line  27:      "PIN13"       unused   input  active-high
line  28: "PCIE_RP1_WAKE" unused input active-high
line  29:   "FAN_TACH"       unused   input  active-high
line  30:   "HOST_SDA"       unused   input  active-high
line  31:   "HOST_SCL"       unused   input  active-high
line  32:  "ETH_RST_N"  "phy-reset"  output   active-low [used]
line  33:          "-"       unused   input  active-high
line  34: "CD0_IO0_MICCLK" "cam0_reg" output active-high [used]
line  35: "CD0_IO0_MICDAT0" unused input active-high
line  36: "RP1_PCIE_CLKREQ_N" unused input active-high
line  37:          "-"       unused   input  active-high
line  38:    "CD0_SDA"       unused   input  active-high
line  39:    "CD0_SCL"       unused   input  active-high
line  40:    "CD1_SDA"       unused   input  active-high
line  41:    "CD1_SCL"       unused   input  active-high
line  42: "USB_VBUS_EN" unused output active-high
line  43:   "USB_OC_N"       unused   input  active-high
line  44: "RP1_STAT_LED" "PWR" output active-low [used]
line  45:    "FAN_PWM"       unused  output  active-high
line  46: "CD1_IO0_MICCLK" "cam1_reg" output active-high [used]
line  47:  "2712_WAKE"       unused   input  active-high
line  48: "CD1_IO1_MICDAT1" unused input active-high
line  49: "EN_MAX_USB_CUR" unused output active-high
line  50:          "-"       unused   input  active-high
line  51:          "-"       unused   input  active-high
line  52:          "-"       unused   input  active-high
line  53:          "-"       unused   input  active-high

Nice! GPIO 9, 10 and 11 marked as Alt0 is exactly as it should be when you have SPI enabled. Looks like it's reading the correct data.

it seems to be doing all the right things. i've asked in the pi forums what's up with the rp1-gpiomem vanishing and multiple gpiomems. it makes life easier in the end not to have to have two different gpiomems to have to check for but i don't recall it being mentioned anywhere and i thought the rp1 doc mentioned rp1-gpiomem

Considering read operations work as expected, that leaves write operations.
That will either require some coding (or using any of your existing code), or using the gpio_blinkled or gpio_blinkled_signals examples with an LED and resistor attached to GPIO 23 (physical pin 16) to see if changing modes and levels works. Another thing to double check would be to write some code to check the level on an input pin while it changes between high and low. It would also be helpful if you could test enabling a pull-up or pull-down and physically checking the voltage on the pin.
Let me know if you need any help with writing up some sample code.

i'll dig out some leds, jumper wires and breadboard

it seems to be doing all the right things. i've asked in the pi forums what's up with the rp1-gpiomem vanishing and multiple gpiomems.

Yeah the whole naming convention is a bit vague to me, but I can at least see the point in using a different name for gpiomem on older Pi models compared to the Pi 5, considering the registers are completely different. On my Pi 4 running Bookworm I'm still only seeing the old gpiomem without any suffix, so at least no changes are needed there. As long as they've settled on this scheme we should be okay.

gpio_blinkled & gpio_blinkled_signals are blinking an led :)
so gpio23 is working :)

Awesome! Thanks for the quick test results. I'm glad it's all going smoothly. That means both mode changes and level changes are working. That just leaves checking an input pin's level with the level getting changed between high and low by some external source, and checking the voltage on an input pin with pull-up/pull-down enabled, both of which will require some coding and external parts/multimeter (happy to help if needed).
It sounds like it's all working as expected though. After you get a chance to check the above-mentioned, that should be the entire GPIO module ready for the Pi 5! While I don't expect any major issues with the other peripherals, if you have any hardware lying around that would let you perform some tests on SPI/I2C/PWM/UART, it would be good to confirm they're still working before launch day.
BTW, the new GPIO registers also give us access to a few new toys (change output drive strength, input Schmitt trigger hysteresis, output slew rate limiter, debounce), but I'll wait until I have my hands on a Pi 5 as well before adding support for those, so something to look forward to for 0.16.0. 😁

i'll dig out all my bits and pieces tomorrow and start playing. i have a few i2c & spi displays & sure i have a few pwm thingies just a matter of finding them

dug out my ds3231 and the example i2c_ds3231.rs seems to work as expected

Great to hear! I wasn't expecting any problems, but it's always good to check.
It looks like rppal is ready for the Pi 5. I'll get 0.15.0 out the door within the next day or two. Thanks again for all the help!

great. i'm looking forward to the release as then i'll be able to try porting one of my last python programs left to rust (& tauri) Pity we don't seem to have a rust equivilent of the python module luma but we can't have everything :)

RPPAL v0.15.0 with Raspberry Pi support is now available!

@golemparts I'm getting the same error in most recent version :(
jezor@raspberry:~$ git clone https://github.com/golemparts/rppal.git
Cloning into 'rppal'...
remote: Enumerating objects: 5079, done.
remote: Counting objects: 100% (824/824), done.
remote: Compressing objects: 100% (120/120), done.
remote: Total 5079 (delta 746), reused 725 (delta 704), pack-reused 4255 (from 1)
Receiving objects: 100% (5079/5079), 1.51 MiB | 6.33 MiB/s, done.
Resolving deltas: 100% (3496/3496), done.

jezor@raspberry:~$ cd rppal

jezor@raspberry:~/rppal$ cargo run --example spi_25aa1024
    Updating crates.io index
     Locking 21 packages to latest compatible versions
      Adding embedded-hal v0.2.7 (latest: v1.0.0)
      Adding nb v0.1.3 (latest: v1.1.0)
   Compiling libc v0.2.158
   Compiling lazy_static v1.5.0
   Compiling rppal v0.19.0 (/home/jezor/rppal)
   Compiling simple-signal v1.1.1
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 4.30s
     Running `target/debug/examples/spi_25aa1024`
Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Thank you @golemparts, this worked!
jezor@raspberry:~/rppal$ cargo run --example spi_25aa1024
    Updating crates.io index
     Locking 21 packages to latest compatible versions
      Adding embedded-hal v0.2.7 (latest: v1.0.0)
      Adding nb v0.1.3 (latest: v1.1.0)
   Compiling libc v0.2.158
   Compiling lazy_static v1.5.0
   Compiling rppal v0.19.0 (/tmp/rppal)
   Compiling simple-signal v1.1.1
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 8.58s
     Running `target/debug/examples/spi_25aa1024`
Bytes read: [0, 0, 0, 0, 0]

I found this issue after I reported mine #154
Was the HW pwn tested and where there OS settings I might have missed that where not documented?

authors: Jezorko golemparts johansmitsnl ukscone

repo: golemparts/rppal

license: mit

license_source: bigquery


text:
fix: use Scratch's FieldAngle

This PR cleans up and slightly modernizes Scratch's FieldAngle implementation, and uses it in favor of the version provided in Blockly Samples.

This fixes #63 and fixes #101.

source: gharchive/pull-request

repo: gonfunko/scratch-blocks


text:
Enable Hold Mode by default on specially crafted map?

Might be useful if there are maps out there that is made specifically for this ruleset. (cough cough like my map here cough cough)
Maybe checking the map's tags if there is somethin like "soyokaze", similar to how Rush! does.
Regardless, cool stuff :)

Resolved in release 2021.1111.0 in commit fa22ce1744d827651cf5838c0e88fddfa874d9f5.
Holds are now generated by default on all maps.

authors: goodtrailer rorre

repo: goodtrailer/soyokaze

license: MIT


text:
Pubsub subscription delete - Incorrect response type

When trying to delete a pubsub subscription using latest master of the generated/gen/pubsub/v1/lib crate:
client
            .projects()
            .subscriptions()
            .delete(SUBSCRIPTION_NAME)
            .execute_with_default_fields()?;

Returns an error like this:
'Couldn't convert to json: Error(Json(Error("invalid type: map, expected unit struct Empty", line: 1, column: 0)))'

With a snipped stack trace of:
  10: core::result::unwrap_failed
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/libcore/macros.rs:18
  11: core::result::Result<T,E>::expect
             at /rustc/eae3437dfe991621e8afdc82734f4a172d7ddf9b/src/libcore/result.rs:827
  12: google_pubsub1::resources::projects::subscriptions::DeleteRequestBuilder::_execute
             at /Users/jason/src/generated/gen/pubsub/v1/lib/src/lib.rs:3863
  13: google_pubsub1::resources::projects::subscriptions::DeleteRequestBuilder::execute_with_fields
             at /Users/jason/src/generated/gen/pubsub/v1/lib/src/lib.rs:3853
  14: google_pubsub1::resources::projects::subscriptions::DeleteRequestBuilder::execute_with_default_fields
             at /Users/jason/src/generated/gen/pubsub/v1/lib/src/lib.rs:3830
  15: gcp_utils::pubsub::tests::init
             at gcp-utils/src/pubsub.rs:21

(the line numbers may not match exactly because I inserted a few lines of debugging help)
Whereas the actual reqwest response that comes back is successful:
Response { url: "https://pubsub.googleapis.com/v1/projects/octomizer/subscriptions/test-subscription-21990", status: 200, headers: {"content-type": "application/json; charset=UTF-8", "vary": "Origin", "vary": "X-Origin", "vary": "Referer", "transfer-encoding": "chunked", "date": "Fri, 20 Sep 2019 17:20:57 GMT", "server": "ESF", "cache-control": "private", "x-xss-protection": "0", "x-frame-options": "SAMEORIGIN", "x-content-type-options": "nosniff", "alt-svc": "quic=\":443\"; ma=2592000; v=\"46,43,39\""} }test pubsub::tests::publish_and_poll_message

It looks like the Ok variant return type of pubsub::v1::lib::DeleteRequestBuilder::execute_with_default_fields is wrongly set to Empty:
                pub fn execute_with_default_fields(
                    self,
                ) -> Result<crate::schemas::Empty, crate::Error> {

But I'm not sure what it should be set to?
If I instead use execute_with_fields(Some("*")) instead of execute_with_default_fields I can work around it, but I need to add an extra .map(|_: serde_json::Value| ()); on the end to help type inference (I'm assuming).

I also just hit this for client.projects().subscriptions().acknowledge(... as well.

I pushed https://github.com/google-apis-rs/generator/commit/aa0890541a82330db7abd5d54c92c400825e8094, which should fix the generator if I understand the issue correctly. I'm not very familiar with how to regenerate the apis in the generated directory unfortunately. I just tried a number of things, but they failed with errors (which sadly matches all my previous experiences). @Byron will know how to regenerate those libs when he  sees this.

I have regenerated all APIs with just refresh-all, and I hope it helps, @binarybana .
Besides that, maybe @ggriffiniii could give me a hint to be able to fix whatever issue is preventing you from doing the same.
Thanks everyone for the enthusiasm :), I can't wait to see this iteration of google-apis-rs in its full async glory!

authors: Byron binarybana ggriffiniii

repo: google-apis-rs/generator


text:
RenderableSource apply custom material

Hi,
since SceneForm 1.5 we got the option to import gltf models at runtime.
Is there a possibility to apply custom material reference to the renderable source?
As i can see you can manipulate only the scale and the recenter mode attributes.

Maybe this issue can help you.

Sounds like a feature that needs to be added.
However, you can work around this issue if you download gltf on your phone , convert it to sfb with a standard material definition , and then do as above. Assign a custom material definition and maps that are used. Not the best way, but it should work.

Hallo @c0deminded
thanks for the response. But as far as I know there is no option to add (not modify) a new custom material at runtime. Or am I blind?

@c0deminded Forget everything I said. Are you f!%&"§& kidding me? I overlooked the setMaterial method.

repo: google-ar/sceneform-android-sdk


text:
Importing .fbx files including animations from 3DsMax ( with dirty solution )

Hello,
Since animations are mandatory for our AR app we have been experimenting with sceneform for quite a while, but until now we were unable to succesfully import files created by 3DsMax in Sceneform with Animations.
Our testing included
a) using different assets from our artists
b) making sure the animations work in Unity and Unreal
c) making sure to apply all settings listed here https://developers.google.com/ar/develop/java/sceneform/animation/obtaining-assets
But no success with sceneform.
However, working with the andy_dance as resource with different programs I figured out that exporting with 3DsMax to Sceneform must be missing some option / default param,
because when importing and then exporting the andy_dance in 3DsMax the animations are gone in Sceneform (gone means 'not playable by the viewer or in java' but the data is there)
However, Importing the file from 3DsMax in Blender  afterwards made its animation reappear in Sceneform
( andy_dance.fbx -> import in 3ds max -> export from 3ds max -> | unplayable in Sceneform | -> import in blender -> export from blender -> | suddenly playable again in Sceneform | )
Also, I confirmed that files created (and exported) by our artists in 3DsMax can be fixed by passing them through blender
While this is a 'solution' for everyone having problems with 3dsmax and sceneform, I would appreciate if you could look into that.
Perhaps there is some mandatory setting not enabled when exporting from 3DsMax, but enabled by default when exporting from blender.
Thanks !

Since the andy_dance model was created by Autodesk maya, I also used it instead of blender in the 'reimport to fix animations' flow and the result is the same as with blender:
Using Autodesk Maya, Importing & exporting a .fbx file created by 3DsMax with animations makes them reapperar in sceneform.
So I can clarify the Issue here:
Exporting animated models with 3DsMax to Sceneform with .fbx as format does not work.
The animation data must be 'still inside' the exported .fbx file, but is not recognizable by sceneform.
Only when importing/exporting the model again using either Autodesk Maya or blender they are recognized by sceneform.

Hello,
We did some more testing and found a better solution.

Background: Someone in our team remembered that when importing from A3DsMax to unreal, it can be neccesary to export a)rig model and b) bones with animations seperately, e.g.
biene_model.fbx and
biene_animation.fbx.
I assume it is done in a similar way with andy_wave_left and right.
While doing exactly as described did not work exactly due to the following error message when viewing it in android studio:
java.lang.RuntimeException: Model(target) expects to resample 54 bones; Animation(source) has 51 bones  at com.google.ar.sceneform.assets.AnimationInstance.nCreateAnimationTarget(Native Method)  at com.google.ar.sceneform.assets.AnimationInstance.createTarget(AnimationInstance.java:23)  at com.google.ar.sceneform.plugin.viewer.FilamentViewer.setupAnimation(FilamentViewer.java:124)  at com.google.ar.sceneform.plugin.viewer.FilamentViewer.access$500(FilamentViewer.java:32)  at com.google.ar.sceneform.plugin.viewer.FilamentViewer$1$1.run(FilamentViewer.java:97)  at com.google.ar.sceneform.plugin.viewer.Filamentor$3.run(Filamentor.java:113)

We managed to bypass this error by adding the animation to biene_model.fbx and then importing biene_model.fbx only, but selecting the file 2 times in the Sceneform importer.

as Source assets path
as Animation files.

This way we finally have animations directly when importing from Autodesk, even though testing took us quite some time and we are still left with #650 :
No textures for our animated models ( textures only work with .obj files out of the box)

I had the same problem.


text:
Linking error on MacOS 11(x86_64), not able to link mujoco with --gc-sections

This was my setup:
user@Macbook-MacBook-Air-4 mujoco_mpc % clang --version
Homebrew clang version 14.0.6
Target: x86_64-apple-darwin20.6.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm@14/bin
user@Macbook-MacBook-Air-4 mujoco_mpc % cmake --version
cmake version 3.27.8

CMake suite maintained and supported by Kitware (kitware.com/cmake).

I have compiled the source using these steps:
git clone https://github.com/google-deepmind/mujoco_mpc.git
cd mujoco_mpc
mkdir build
cd build
export CC=clang
export CXX=clang++
cmake .. -G Ninja -DMJPC_BUILD_GRPC_SERVICE:BOOL=ON
ninja

As I have seen at: https://github.com/google-deepmind/mujoco_mpc/blob/main/.github/workflows/build.yml
[108/2754] Linking CXX shared library lib/libmujoco.3.0.1.dylib
FAILED: lib/libmujoco.3.0.1.dylib
: && /usr/local/opt/llvm@14/bin/clang++ -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -mmacosx-version-min=11.7 -dynamiclib -Wl,-headerpad_max_install_names -mmacosx-version-min=11 -Wl,-no_weak_imports -fuse-ld=lld -Wl,--gc-sections -current_version 3.0.1 -o lib/libmujoco.3.0.1.dylib -install_name @rpath/libmujoco.3.0.1.dylib _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_callback.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_box.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_convex.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_driver.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_primitive.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_collision_sdf.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_core_constraint.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_core_smooth.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_crossplatform.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_derivative.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_derivative_fd.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_forward.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_inverse.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_island.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_io.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_passive.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_plugin.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_print.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_ray.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_resource.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_sensor.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_setconst.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_solver.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_support.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_blas.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_errmem.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_misc.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_solve.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_sparse.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_util_spatial.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vfs.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_init.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_interact.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_state.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/engine/engine_vis_visualize.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_composite.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_flexcomp.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_mesh.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_model.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_objects.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/user/user_util.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_api.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_base.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_native_reader.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_numeric_format.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_native_writer.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_urdf.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/xml/xml_util.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/glad/glad.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/glad/loader.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_context.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_gl2.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_gl3.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/render/render_util.c.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/thread/thread_pool.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/thread/thread_task.cc.o _deps/mujoco-build/CMakeFiles/mujoco.dir/src/ui/ui_main.c.o  lib/libccd.a  lib/liblodepng.a  lib/libqhullstatic_r.a  lib/libtinyobjloader.a  lib/libtinyxml2.a  /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/lib/libm.tbd  -lm && :
ld64.lld: error: unknown argument '--gc-sections'
clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
[113/2754] Building CXX object _deps/googletest-build/googletest/CMakeFiles/gtest.dir/src/gtest-all.cc.o
ninja: build stopped: subcommand failed.

I had to comment out some lines in cmake/MujocoLinkOptions.cmake to not build with --gc-sections, but I think it can be done better

The errors you were experiencing are likely related to dependency issues that have since been resolved. If you are still experiencing the issues described above please reopen this issue.
You can also remove gRPC if you don't plan to use the Python API (macOS):
git clone https://github.com/google-deepmind/mujoco_mpc.git
cd mujoco_mpc
mkdir build
cd build
cmake .. -G Ninja -DMJPC_BUILD_GRPC_SERVICE:BOOL=OFF
cmake --build . --config=Release --target mjpc
./bin/mjpc

still getting errors by running the above sequence of commands
ld64.lld: error: unknown argument '--gc-sections'

This is weird because in the config step this is written out:
-- Performing Test SUPPORTS_GC_SECTIONS
-- Performing Test SUPPORTS_GC_SECTIONS - Success

I don't have permission to reopen this issue

authors: keszegrobert thowell


text:
Android Basics: ViewModel

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-training-viewmodel?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-kotlin-unit-3-pathway-3%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-training-viewmodel#6
In which task and step of the codelab can this issue be found?
Task 7 - Step 8
Describe the problem
backing field  "_currentWordCount" is referred to here but this is not yet defined or initialized
this is conducted in Task 11 - Step 2
Steps to reproduce?
N/A
Versions
N/A
Additional information
N/A

Closing - realised this is a duplicate issue so no needed.


text:
Add images: Android Basics with Compose

URL of codelab
https://developer.android.com/codelabs/basic-android-kotlin-compose-add-images?continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fandroid-basics-compose-unit-1-pathway-3%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fbasic-android-kotlin-compose-add-images#1
In which task and step of the codelab can this issue be found?
Add an image to your project

In this task, you'll download an image from the internet and add it to your Happy Birthday app.

Open the image for your birthday card app from this link.
Click Download.

Describe the problem
The link in step 2 is broken and should be fixed.
Steps to reproduce?

Go to the url above
Click on the link above
See error...

Versions
Android Studio version: Android Studio Flamingo | 2022.2.1 Patch 1
API version of the emulator:
Additional information
I was able to root around in the folder structure and find it here:
https://github.com/google-developer-training/basic-android-kotlin-compose-birthday-card-app/tree/main/app/src/main/res/drawable-nodpi
Include screenshots if they would be useful in clarifying the problem.

Thanks for the correct image path.

Hi @pnwbob
Thank you for writing in with this issue.
The lesson has been updated to address it and has recently been republished.
Hope you are enjoying the course!
Regards.

authors: heidy-miguel johnshea pnwbob


text:
buildscript ext does not work

URL of codelab https://github.com/google-developer-training/basic-android-kotlin-compose-training-dessert-clicker/tree/main
In which task and step of the codelab can this issue be found?
Set up dependencies
Describe the problem
buildscript ext does not work
Steps to reproduce?

Add in build.gradle.kts
buildscript {
ext {
lifecycle_version = '2.5.1'
}
}
See error...
Unresolved reference: ext

Versions
Android Studio version:  Giraffe 2022.3.1 Patch 2
API version of the emulator: 32
Additional information
Include screenshots if they would be useful in clarifying the problem.

I fixed it this way for myself:
In build.gradle.kts instead of that sample code define it this way:
buildscript {     extra.apply {         set("lifecycle_version", "2.5.1")     } }
Then in app/build.gradle add two things
Before dependiencies block add:
val lifecycle_version = rootProject.extra["lifecycle_version"]
In dependencies  add:
implementation("androidx.lifecycle:lifecycle-viewmodel-compose:$lifecycle_version")
Hope this helps you.

authors: patrykharanczyk plugie


text:
Android Basics: Viewmodel and State in Compose - Write Unit Test codelab

The solution code doesn't pass unit test.

In gameViewModel_Initialization_FirstWordLoaded test, gameUiState.currentWordCount should be equal to 0.
In updateGameState(updatedScore: Int)  function in GameViewModel class, we missed a currentWordCount = currentState.currentWordCount.inc(), at the last round of the game, which cause the gameViewModel_AllWordsGuessed_UiStateUpdatedCorrectly test to fail.

Agreed, I thought that I was losing my mind so I'm glad to see I'm not the only one.

Duplicate of #31, #30, #19, #12, #4.

authors: osuleymanova rexkekeke scolton99


text:
fix readme typo

Python release type should refer to https://github.com/googleapis/python-storage

@googlebot I signed it!

@x1ah thank you 👍


text:
ValueError: Must specify max_steps > 0, given: 0

$python3 electra_small/run_finetuning.py \
--data-dir $DATA_DIR \
--model-name "ELECTRA-small" \
--hparams '{"model_size": "small", "task_names": ["<task_name>"], "num_trials": 5, "learning_rate": 3e-4, "train_batch_size": 16, "use_tpu": "True", "num_tpu_cores": 8, "tpu_name": "<tpu_name>", "tpu_zone": "europe-west4-a", "gcp_project": "<gcp_name>", "vocab_size": 50000, "num_train_epochs": 10}'

I am getting the following error. Is there something I am missing?
Training for 0 steps
ERROR:tensorflow:Error recorded from training_loop: Must specify max_steps > 0, given: 0
Traceback (most recent call last):
  File "electra_small/run_finetuning.py", line 323, in <module>
    main()
  File "electra_small/run_finetuning.py", line 319, in main
    args.model_name, args.data_dir, **hparams))
  File "electra_small/run_finetuning.py", line 270, in run_finetuning
    model_runner.train()
  File "electra_small/run_finetuning.py", line 183, in train
    input_fn=self._train_input_fn, max_steps=self.train_steps)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/tpu/tpu_estimator.py", line 3035, in train
    rendezvous.raise_errors()
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/tpu/error_handling.py", line 136, in raise_errors
    six.reraise(typ, value, traceback)
  File "/usr/local/lib/python3.5/dist-packages/six.py", line 703, in reraise
    raise value
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/tpu/tpu_estimator.py", line 3030, in train
    saving_listeners=saving_listeners)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/estimator.py", line 358, in train
    'Must specify max_steps > 0, given: {}'.format(max_steps))
ValueError: Must specify max_steps > 0, given: 0

Can anyone help.
Still getting the same error
:~$ python3 electra_small/run_finetuning.py --data-dir "gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/" --model-name "covidECTRA-small" --hparams '{"model_size": "small", "task_names": ["bc5c"], "num_trials": 5,"learning_rate": 3e-4, "train_batch_size": 16, "use_tpu": "True", "num_tpu_cores": 8, "tpu_name": "my_tpu", "tpu_zone": "europe-west4-a", "gcp_project": "my_p", "vocab_size": 50000, "num_train_epochs": 60, "model_dir":"gs://my_bucket/pretraining_data/models/covidECTRA-Small/", "vocab_file":"gs://my_bucket/pretraining_data/vocab.txt"}'

================================Config: model=ELECTRA-small, trial 1/5==============================
answerable_classifier True
answerable_uses_start_logits True
answerable_weight 0.5
beam_size 20
data_dir gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/
debug False
do_eval True
do_lower_case True
do_train True
doc_stride 128
double_unordered True
embedding_size None
eval_batch_size 32
gcp_project covidectra
init_checkpoint gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/models/ELECTRA-small
iterations_per_loop 1000
joint_prediction True
keep_all_models True
layerwise_lr_decay 0.8
learning_rate 0.0003
log_examples False
max_answer_length 30
max_query_length 64
max_seq_length 128
model_dir gs://my_bucket/pretraining_data/models/ELECTRA-Small/
model_hparam_overrides {}
model_name ELECTRA-small
model_size small
n_best_size 20
n_writes_test 5
num_tpu_cores 8
num_train_epochs 60
num_trials 5
predict_batch_size 32
preprocessed_data_dir gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/models/covidECTRA-small/finetuning_tfrecords/bc5c_tfrecords
qa_eval_file <built-in method format of str object at 0x7fa57ed85030>
qa_na_file <built-in method format of str object at 0x7fa57edf03a0>
qa_na_threshold -2.75
qa_preds_file <built-in method format of str object at 0x7fa57ed850d8>
raw_data_dir <built-in method format of str object at 0x7fa57dba8e00>
results_pkl gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/models/ELECTRA-small/results/bc5c_results.pkl
results_txt gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/models/ELECTRA-small/results/bc5c_results.txt
save_checkpoints_steps 1000000
task_names ['bc5c']
test_predictions <built-in method format of str object at 0x7fa57dba41a0>
tpu_job_name None
tpu_name my_tpu
tpu_zone europe-west4-a
train_batch_size 16
use_tfrecords_if_existing True
use_tpu True
vocab_file gs://my_bucket/pretraining_data/vocab.txt
vocab_size 50000
warmup_proportion 0.1
weight_decay_rate 0.01
write_test_outputs True

Loading dataset bc5c_train
================================================================================
Start training: model=ELECTRA-small, trial 1/5
================================================================================
Training for 0 steps
ERROR:tensorflow:Error recorded from training_loop: Must specify max_steps > 0, given: 0
Traceback (most recent call last):
  File "electra_small/run_finetuning.py", line 323, in <module>
    main()
  File "electra_small/run_finetuning.py", line 319, in main
    args.model_name, args.data_dir, **hparams))
  File "electra_small/run_finetuning.py", line 270, in run_finetuning
    model_runner.train()
  File "electra_small/run_finetuning.py", line 183, in train
    input_fn=self._train_input_fn, max_steps=self.train_steps)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/tpu/tpu_estimator.py", line 3035, in train
    rendezvous.raise_errors()
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/tpu/error_handling.py", line 136, in raise_errors
    six.reraise(typ, value, traceback)
  File "/usr/local/lib/python3.5/dist-packages/six.py", line 703, in reraise
    raise value
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/tpu/tpu_estimator.py", line 3030, in train
    saving_listeners=saving_listeners)
  File "/usr/local/lib/python3.5/dist-packages/tensorflow_estimator/python/estimator/estimator.py", line 358, in train
    'Must specify max_steps > 0, given: {}'.format(max_steps))
ValueError: Must specify max_steps > 0, given: 0

When I check the GCS:
gs://my_bucket/pretraining_data/finetuning_data/BC5CDR-chem/models/ELECTRA-small/finetuning_tfrecords/bc5c_tfrecords
I found out the tfrecord file is not created. It's file size is 0 B

I had the same problem, and my error was because the dataset did not have a separator, such as adding a blank line after a sentence of text.

Okay. Thank you.
My mistake was that I was passing a different sequence length. Now it works fine. But fine-tuning is not working. For some reason, I get zero for all metrics

Excuse me, have you solved this problem? Thank you.

authors: bean9610 etetteh xiangrukui

repo: google-research/electra


text:
A1 motion retarget config + binary tweaks.

Added retarget_config_a1.py to enable retargeting dog motions to A1
robot.

Set robot to its default pose before retargeting. The inverse
kinematics starts from the robot's current pose, so this biases it to
get the knees bending in the right direction.

Added motion_imitation to the path. Without this the motion_util
import fails.

Nice, thanks for the contribution! LGTM.

authors: erwincoumans priority-kew


text:
Bugfix

Fixes a bug in SymmetricBackend.eigs and SymmetricBackend.eigsh_lanczos due to wrong raveling of tensor data.
Fixes #809

Codecov Report

Merging #808 into master will increase coverage by 0.01%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #808      +/-   ##
==========================================
+ Coverage   98.22%   98.24%   +0.01%
==========================================
  Files         125      125
  Lines       21163    21278     +115
==========================================
+ Hits        20788    20905     +117
+ Misses        375      373       -2

Impacted Files
Coverage Δ

...sornetwork/backends/symmetric/symmetric_backend.py
99.13% <100.00%> (ø)

...twork/backends/symmetric/symmetric_backend_test.py
99.67% <100.00%> (+0.04%)
:arrow_up:

tensornetwork/block_sparse/blocksparsetensor.py
98.96% <0.00%> (+0.51%)
: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 ba9c95a...99420d5. Read the comment docs.

authors: codecov-commenter mganahl

repo: google/TensorNetwork


text:
Typo in lab "scripting the service worker" section 6: needs to change "server worker" to "service worker"

Page Affected: https://codelabs.developers.google.com/codelabs/pwa-scripting-the-service-worker/#5
What needs to be done:
Correct the typo by changing "server worker" to "service worker"

I will be taking up the responsibility of fixing the typo. Will submit a PR now

repo: google/WebFundamentals


text:
[Swipe to refresh] Indicator stuck on Android 12 stretch overscroll effect

Description
If you stop the pull motion briefly and then resume the motion, the indicator will stay at the same place and the motion propagates down to the LazyColumn to trigger the overscroll effect.
Note: this does not happen with the legacy overscroll effect (prior to android 12)! It only happens with the "new" stretch overscroll effect.
This only happens if the motion is interrupted and the finger stays on the screen without any movement and then resumes.
Video:
https://user-images.githubusercontent.com/22662033/156323093-906214aa-40d6-4963-aa83-fb9e432fcbe4.mp4
Steps to reproduce
@Composable
fun PagerIssue() {
    var isRefreshing by remember { mutableStateOf(false) }

    SwipeRefresh(
        modifier = Modifier.fillMaxSize(),
        state = rememberSwipeRefreshState(isRefreshing),
        onRefresh = { isRefreshing = true },
    ) {
        LazyColumn(
            Modifier.fillMaxSize()
        ) {
            items(100) { index ->
                Text("I'm item Nr. $index")
            }
        }
    }

    LaunchedEffect(isRefreshing) {
        if (isRefreshing) {
            delay(1000)
            isRefreshing = false
        }
    }
}

Expected behavior
Upon resume of the motion, the indication should continue it's movement and continue the pull to refresh motion/action.
Additional context
This problem can be worked around by wrapping the content of the SwipeRefresh composable with a CompositionLocalProvider which provides null as LocalOverScrollConfiguration while state.isSwipeInProgress is true:
@Composable
fun SwipeRefreshWithoutOverscroll(
    state: SwipeRefreshState,
    onRefresh: () -> Unit,
    modifier: Modifier = Modifier,
    swipeEnabled: Boolean = true,
    refreshTriggerDistance: Dp = 80.dp,
    indicatorAlignment: Alignment = Alignment.TopCenter,
    indicatorPadding: PaddingValues = PaddingValues(0.dp),
    indicator: @Composable (state: SwipeRefreshState, refreshTrigger: Dp) -> Unit = { s, trigger ->
        SwipeRefreshIndicator(s, trigger)
    },
    clipIndicatorToPadding: Boolean = true,
    content: @Composable () -> Unit,
) {
    SwipeRefresh(
        state = state,
        onRefresh = onRefresh,
        modifier = modifier,
        swipeEnabled = swipeEnabled,
        refreshTriggerDistance = refreshTriggerDistance,
        indicatorAlignment = indicatorAlignment,
        indicatorPadding = indicatorPadding,
        indicator = indicator,
        clipIndicatorToPadding = clipIndicatorToPadding,
    ) {
        val overscrollConfiguration = if (state.isSwipeInProgress) {
            null
        } else {
            LocalOverScrollConfiguration.current
        }
        CompositionLocalProvider(LocalOverScrollConfiguration provides overscrollConfiguration) {
            content()
        }
    }
}

Maybe this is also the solution to take as a PR?
Personally i see no reason why the underlying scroll view should have any overscroll effect while isSwipeInProgress is true as the SwipeRefresh composable should handle all motion events.

Thanks for the report. For the proposed solution, wouldn't you still need overscroll for when you hit the bottom of the list?

Oh sorry I misread, it's only while a swipe is in progress. That does seem like a good fix at second glance. Feel free to put up a PR and I will review!

@bentrengrove I'm working on the PR now but got one question;
In your samples i have an issue which strangely enough i don't have in my code; isSwipeInProgress is set to true while regularily scrolling down a lazy column.
Upon investigation i found that isSwipeInProgress is set to true inside the NestedScrollConnection's onPostScroll even if the remaining y is positive.
Now my question is why is isSwipeInProgress set to true in the NestedScrollConnection's onPostScroll if the remaining y is positive?
Shouldn't it be only true on a positive y if also the indicator's offset is greater than 0 indicating that a swipe has happend previously and this down motion basically cancels the swipe?
This basically leads to the issue with my suggested fix that the overscroll is also disabled when the user reaches the end of the list at the bottom.

Simply wrapping the state.isSwipeInProgress = true inside
        if (available.y > 0) {
            state.isSwipeInProgress = true
        }

or moving it out of onScroll to only be executed in onPostScroll seems to fix the issue but I'm uncertain if this does not impose any other issues.
With this fix it would certainly need to be revisited for https://github.com/google/accompanist/pull/541 to take the other direction into account.

So basically the isSwipeInProgress is not correct with the current implementation if the user starts a pull to refresh, aborts it and starts scrolling down as isSwipeInProgress is only set to false once onPreFling triggers which only happens upon release.
But as far as i can see it should also be set to false during the motion once the scrolling of the list begins when the indicator is gone again.
This would take care of that:
        if (available.y > 0) {
            state.isSwipeInProgress = true
        } else if (state.indicatorOffset.roundToInt() == 0) {
            state.isSwipeInProgress = false
        }

But again with https://github.com/google/accompanist/pull/541 we would need to take the direction into account.
@bentrengrove should i do two separate PR's for this as these are basically two separate issues or should i do the fix with the PR for this issue?
Or do i miss something with my proposed fix for the isSwipeInProgress state not being upToDate/correct?

Why it is closed? Issue is actual.

Just tested new build with fix, issue is not fixed fully, sometimes circle still freezing allowing overscroll list animation :(

^^^

Any news about this issue? It's still happening for me.

Related? https://issuetracker.google.com/issues/248274004

authors: Ironova TomBell-Trove bentrengrove chippmann demidenko phamsarah

repo: google/accompanist


text:
Enable fast unaligned access for aosp

Maybe we can add this to clang driver once we have tested it?

aosp testing in progress: https://android-review.googlesource.com/c/platform/build/soong/+/2734373

Maybe we can add this to clang driver once we have tested it?

oh, definitely --- any time we land something in AOSP (and we feel like it's really landed and isn't going to get reverted), we should start moving it upstream. any time i don't suggest that to you is a bug on my part :-)
(the alternative is that every single build system has to add these flags, which obviously doesn't scale.)

merged.

i think it is okay to keep it open as the currently used (backend) flags will be updated (to -munaligned-access) with the new toolchain.

Any reason not to use -mno-strict-align, which is common with GCC?

Bumping this thread because the last comment mentions we'll have 'unaligned-access' in the new toolchain, and I believe we've completed a round of updates since Oct.
@appujee - should we be switching our flags to "-munaligned-access" now? WDYT about @SiFiveHolland 's comments on 'no-strict-align'?

yes, -munaligned-access flag works with the latest clang update.

I'll replace the previous workaround with -munaligned-access

is there a reason we haven't moved this into the driver yet? this flag has been in AOSP for a long time now with no problems...

The change landed few weeks back, https://android-review.googlesource.com/c/platform/build/soong/+/2977952 I forgot to close this bug.

Interestingly -munaligned-access  was replaced by -mno-strict-align in llvm upstream a few days back. Both flags were aliases. Pirama has change to that effect https://android-review.googlesource.com/c/platform/build/soong/+/3002035

I'll  enable the flag by default for Android. https://github.com/llvm/llvm-project/pull/85704 WIP.

the llvm change was merged ... is that cherrypicked for our llvm? (and is that cherrypick in the toolchain that we're working on currently for the forthcoming ndk release, or is it for the next one?)

it was cherry-picked to our llvm in https://android-review.googlesource.com/c/toolchain/llvm_android/+/3009313 it is not in the toolchain (clang-r522817) we are working on.

@appujee --- is this in our current clang?

yes https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86/+/refs/heads/main/clang-r530567/clang_source_info.md

authors: SiFiveHolland appujee enh-google prashanthswami