text:
x/pkgsite: invalid versions for subdirectories

What is the URL of the page with the issue?
https://pkg.go.dev/github.com/gomodule/redigo/redis
What is your user agent?

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.51 Safari/537.36
Screenshot

First go to the URL directly

Second clicks the sub directory link from the main repo, which shows the latest link in red indicating the link from latest gomodules/redigo doesnt link to the latest gomodules/redigo/redis which should be the same.

Versions aren't listed in the sub directory:

What did you do?
Two flows:
Issue 1

Go to the redis main page with no version: https://pkg.go.dev/github.com/gomodule/redigo/redis
See that the version is: v0.0.0-...-e14091d instead of 1.8.8 which is currently the latest.

Issue 2

Go to to the page repo root: https://pkg.go.dev/github.com/gomodule/redigo
Click Directories -> redis link
See the second image above where the "Go to Latest" button is red and shouldn't be

What did you expect to see?
Sub directories in repos use the latest version by default.
What did you see instead?
Sub directories doesn't even list any version
Relevant information
We redigo have an experimental v2.0.0 branch before go modules we're introduced which has been challenging. With the introduction of retract in v1.16 we recently retracted this version in this commit so wondering if this is an edge case which pkgsite isn't dealing with?
Thanks for pabigot for raising this https://github.com/gomodule/redigo/issues/602

Thanks for the quick response @seankhliao :)
To clarify github.com/gomodule/redigo/redis was never a separate module, the blog post seems to deal with the case it was but this is not the case.
As far as I can see all other go tools seem to work as expected. So for example if I use github.com/gomodule/redigo/redis in a package and run go mod tidy it knows that the latest version is v1.8.1 the same for go get
go mod tidy
go: finding module for package github.com/gomodule/redigo/redis
go: found github.com/gomodule/redigo/redis in github.com/gomodule/redigo v1.8.8

go get -v github.com/gomodule/redigo/redis@latest
go: added github.com/gomodule/redigo v1.8.8

Prior to adding the retract to the go.mod this wasn't the case and it would pick up a v2.0.0+incompatible.
So unless I'm missing something, it seems like x/pkgsite is the only part of the ecosystem which doesn't correctly follow the chain and result in the correct versions?

The second issue is working as intended, go modules match to the longest module name.

To clarify when you say second issue do you mean the versions not listing correctly?
If so this isn't how something like testify/require is working and hence shows the versions associate with parent.

The redis submodule certainly existed at some point: https://github.com/gomodule/redigo/blob/e14091dffc1b085ace903ff7c41916e17c2daca3/redis/go.mod
(Clicking "valid go.mod file on the pkgsite sidebar will take you there).
go tooling chooses the correct one because 1. tagged overrides plain commits, and 2. it checks for the existence of a matching package (the redis module at the tagged version is empty).
Users only need to use a single version, so that works for them, but pkgsite needs to work with all versions (past, present, and future), so it can't follow the same logic. If a module exists/existed without being retracted, it will be served.
The only way to fix this is to properly retract the redis module, serving a module without files like the v0.0.0-do-not-use you have now isn't the correct fix.

Thanks for the clarification on why pkgsite is special, makes sense.
The blog article details how to retract a module which has been tagged, but not clear how to do the same for one that has never been tagged.
I thought I understood your statement:

The only way to fix this is to properly retract the redis module, serving a module without files like the v0.0.0-do-not-use you have now isn't the correct fix.

To mean that we would need a redis/go.mod and redisx/go.mod with:
retract v0.0.0-do-not-use // Never used only present to fix pkg.go.dev.

But re-reading I'm not sure this was your intention?

I can't speak to the right way to do this, but I thought that "you can file a request for the pkgsite team to remove your package" from https://pkg.go.dev/about#removing-a-package might be a workable approach?  gomodule/redigo#604 kinda scares me.

you would need:
// redis/go.mod
module github.com/gomodule/redigo/redis

retract [v0.0.0-0, v0.0.1]

and tag it as redis/v0.0.1.

you need to cover any plain commits with the go.mod file
v0.0.0-do-not-use already existed/exists, and you need a version that counts as newer (by semver).

The next commit has to be to remove the file (unless you do it on some other branch and just leave it there).
Removing a module by request will likely impact the module you want to keep as it shares a path.

Thanks again @seankhliao I've prepared a PR that includes the changes you suggested.
Note that no go.sum files present, would appreciate a review to ensure everything looks good?
As @pabigot mentioned I'm not totally comfortable with this as if it doesn't work or creates any unintended impact, I don't know a way to fix as the tag v0.0.1 will exist, which isn't ideal.

The tag only needs to exist long enough for the proxy to index/cache it. If you do it wrong, bump up the version and try again, the retractions at the highest version are the ones take effect.

Is there a way to force the proxy to index/cache it?

For those which might find this issue I managed to trigger the index to cache it by manually visiting:
https://pkg.go.dev/github.com/gomodule/redigo/redis@v0.0.1
https://pkg.go.dev/github.com/gomodule/redigo/redisx@v0.0.1
Thanks @seankhliao for the help in figuring out how to fix.

authors: pabigot seankhliao stevenh


text:
runtime/metrics: data race detected in Read

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

$ go version
go version go1.18.3 darwin/arm64

Does this issue reproduce with the latest release?
Yes, still reproducible with 1.19beta1.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GO111MODULE=""
GOARCH="arm64"
GOBIN=""
GOCACHE="/Users/cristian/Library/Caches/go-build"
GOENV="/Users/cristian/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/cristian/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/cristian/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/homebrew/Cellar/go/1.18.3/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/homebrew/Cellar/go/1.18.3/libexec/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.18.3"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/98/fgzhqvmx7x1d61fqsvw9cg9m0000gn/T/go-build1308397819=/tmp/go-build -gno-record-gcc-switches -fno-common"
GOROOT/bin/go version: go version go1.18.3 darwin/arm64
GOROOT/bin/go tool compile -V: compile version go1.18.3
uname -v: Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:29 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T8101
ProductName:	macOS
ProductVersion:	12.4
BuildVersion:	21F79
lldb --version: lldb-1316.0.9.46
Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)

What did you do?
runtime/metrics says that "It is safe to execute multiple Read calls concurrently". However, running the following code with race detector enabled suggests a data race. Unsure whether this is a false positive (metrics.Read uses a semaphore lock).
package main

import (
        "fmt"
        "runtime/metrics"
        "sync"
)

func main() {
        var wg sync.WaitGroup

        for i := 0; i < 2; i++ {
                wg.Add(1)
                go func() {
                        sample := make([]metrics.Sample, 1)
                        sample[0].Name = "/gc/heap/allocs:bytes"
                        metrics.Read(sample)
                        fmt.Printf("bytes allocated: %d\n", sample[0].Value.Uint64())
                        wg.Done()
                }()
        }

        wg.Wait()
}

What did you expect to see?
No race detected.
What did you see instead?
Data race detected.
$ go run -race main.go
bytes allocated: 511392
==================
WARNING: DATA RACE
Read at 0x00c000100030 by goroutine 8:
  runtime.evacuate_fast64()
      /opt/homebrew/Cellar/go/1.18.3/libexec/src/runtime/map_fast64.go:376 +0x3fc
  runtime/metrics.runtime_readMetrics()
      /opt/homebrew/Cellar/go/1.18.3/libexec/src/runtime/metrics.go:563 +0xc0

Previous write at 0x00c000100030 by goroutine 7:
  runtime.mapaccess2_faststr()
      /opt/homebrew/Cellar/go/1.18.3/libexec/src/runtime/map_faststr.go:108 +0x43c
  runtime.initMetrics()
      /opt/homebrew/Cellar/go/1.18.3/libexec/src/runtime/metrics.go:67 +0x254

Goroutine 8 (running) created at:
  main.main()
      /Users/cristian/Desktop/main.go:14 +0x50

Goroutine 7 (finished) created at:
  main.main()
      /Users/cristian/Desktop/main.go:14 +0x50
==================
bytes allocated: 552264
Found 1 data race(s)
exit status 66

CC @golang/runtime

I believe this is a false positive, as semacquire/semrelease aren't race instrumented.
cc @mknyszek

Given that readMetrics and initMetrics are both in package runtime (readMetrics is linknamed to runtime/metrics, but race instrumentation just looks at the package we're compiling), why did this get any race instrumentation at all?

Oh, readMetrics didn't get any race instrumentation. The race instrumentation in this case is hand-coded in the map implementation (and hence insensitive to what package it's being called from). Probably we just need a little manual race instrumentation around the map usage in the metrics code.

This isn't new in 1.19, so it doesn't have to be a release-blocker. It's also probably easy to fix, so for now I'll leave it marked just so we don't lose track.

@gopherbot please backport to 1.17 and 1.18.
This triggers a false positive in the race detector for programs calling runtime/metrics.Read from multiple goroutines. There is a workaround: use a single global lock around all calls to metrics.Read in the program. However, that is quite invasive and has serious performance implications for a high-performance API.

I don't think it is necessary. Maps aren't too widely used in the runtime, and I'd prefer us to be able to expand the number of races in the runtime rather than turning it off. It would be nice to catch these quicker though.

I recall Windows callback is another place that uses a map and causes false race, #50249 .

Argh. I sent a fix for that too, but that one is nastier because it is called prior to scheduler initialization, which is fine for the raceread/racewrite in the map, but not raceacquire/racerelease.

That one does me a bit more inclined to turn it off in the map.

FWIW, I did a quick benchmark. A non-race map access is ~3ns. A race map access is ~17ns. With an additional runtime pc check (for runtime. prefix), a map access is ~32ns [1].
This isn't horrible given we're in race mode, but it is still pretty large.
[1] My map was in runtime_test, so the string comparison had to go through most of the characters before failing.

Thanks for the benchmark.
There are a few places where we check whether a PC is in the runtime. Maybe we could provide a 1-bit metadata for whether a function is a runtime function, to avoid the string comparison. But I guess in this case most of the overhead is probably the PC lookup, instead of the string comparison. Maybe we could make it simply an address range comparison, as the linker already lay out runtime functions together (mostly, I think).

source: gharchive/issue

authors: aclements cherrymui cristiangreco ianlancetaylor prattmic

repo: golang/go

license_type: permissive

license_source: github-api


text:
x/vuln: add unit tests for runSource and runBinary

In addition to .ct tests, we should have unit tests for these functions

Obsolete.

authors: tatianab zpavlinovic


text:
x/pkgsite/cmd/pkgsite: local pkgsite with -proxy doesn't use netrc auth to private GOPROXY

What did you do?
Attempted to use a .netrc file to provide credentials to pkgsite for use when fetching via a private GOPROXY.
The regular go mod commands are able to do this, so with a properly configured .netrc file the following succeeds:
GOPROXY="https://goproxy.company.com" go mod download -x github.company.com/org/repo@latest

But attempting to view the documentation of github.company.com/org/repo via pkgsite:
GOPROXY="https://goproxy.company.com" pkgsite -proxy

Fails with 401 authentication errors as the internal/proxy/client.go code doesn't attempt to insert authentication headers, unlike cmd/go which does
What did you expect to see?
pkgsite should be able to use authentication against a private GOPROXY
What did you see instead?
pkgsite does not pass authentication headers to the http requests it makes to a private GOPROXY

Did you ever find a solution to this? I finally managed to configure athens proxy to get private repos, but the links rendered by pkgsite frontend aren't pointing at the right files.

For anyone else who runs into this issue, I managed to work around it by passing HTTP_PROXY and HTTPS_PROXY to frontend and running a custom proxy server that injects credentials from netrc. Really ugly, but it works without having to modify pkgsite source.

authors: dnwe mxk


text:
proposal: go/types: add set data type

Hi there,
I'd like to propose the addition of a set data type to the go/types package. Sets are a fundamental data structure widely used in various applications for efficient membership testing and eliminating duplicates. By introducing a native set type, we can simplify code, improve readability, and enhance performance.
Motivation:

Simplicity: Currently, developers often implement sets using maps or slices, resulting in boilerplate code and reduced clarity. A built-in set type would streamline this process.

Performance: A dedicated set type can be optimized for common set operations like membership checks, union, intersection, and difference, leading to improved runtime efficiency.

Code Readability: Introducing a set type would enhance code readability by making intentions clearer and reducing the need for workarounds.

Design:

The set type can be implemented as a wrapper around a map with an empty struct type (map[T]struct{}), where T represents the element type.

Methods can include Add, Remove, Contains, Union, Intersection, and Difference, providing a comprehensive set of operations.

Compatibility with the existing range loop can be achieved by making the set type implement the Iterable interface.

Example Usage:
package main

import (
	"fmt"
	"go/types"
)

func main() {
	s := types.NewSet()
	s.Add(1, 2, 3)
	s.Add(3, 4, 5)

	if s.Contains(2) {
		fmt.Println("Set contains 2")
	}

	// More operations...
}

Impact:
The introduction of a native set type in the go/types package would lead to more idiomatic and efficient Go code, benefiting both new and experienced developers. It would also align with Go's philosophy of simplicity and efficiency.
Thanks,
Andrea Bruno

go/types implements the go type system, this is useful if you are writing compilers, linters, ... it has nothing to do with types for programs. The representation of your set type in go/types would be as instance of go/types.Struct.
You should really find an other place for it, like a new package such as set idk.
map[T]struct{} usually gets the job done for me, if set would use runtime hooks to provide more efficient implementations of Union, Intersection, and Difference this could be interesting.

Hi @Jorropo thanks for your opinion.
I understand your concern about where to place the set functionality. However, I believe the focus should be on having a native set data structure in Go, which can enhance code readability and performance. Whether it’s in the go/types package or a separate one, the important thing is to provide developers with this useful tool.

I'm going to mark this as a dup of the previous discussion.
A more fully fleshed out proposal can come later

Duplicate of #47331

authors: Jorropo andybbruno seankhliao


text:
net/http: requests with "Transfer-Encoding: chunked" body may buffer small chunks

Hello,

I am attempting to implement a client for a http fanout service in go. The utility
establishes an http connection and makes a POST request with a "Transfer-Encoding:
chunked" body, then reads data from stdin and writes them as individual chunks to
the request body.

I have noticed that small chunks are buffered instead of flushed to the wire
immediately. This seems to happen because the io.Reader initialized in the Request.Body
is wrapped in a bufio.Reader when building the persistent connection:
http://golang.org/src/pkg/net/http/transport.go#L509

The bufio.Reader is initialized with the default buffer size (defaultBufSize = 4096) so
chunks smaller than this size are buffered internally before sent to the wire. In my
opinion these chunks should be flushed to the wire no matter the size.

What steps will reproduce the problem?
1. run ngrep to sniff the TCP packets sent to port 8080: "ngrep -W byline -d lo0
port 8080"
2. start a basic web server on port 8080: "{ sleep 5 ; echo -ne "HTTP/1.1 200
OK\r\nContent-Length: 0\r\n\r\n" ; } | nc -l 8080"
3. run http://play.golang.org/p/CZaWdr4oft

What is the expected output?

The expected output from ngrep should have 3 separate TCP packets sent from the go
process to the server:

ngrep -W byline -d lo0 port 8080
interface: lo0 (127.0.0.0/255.0.0.0)
filter: (ip) and ( port 8080 )
#####
T 127.0.0.1:52415 -> 127.0.0.1:8080 [AP]
POST / HTTP/1.1.
Host: 127.0.0.1:8080.
User-Agent: Go 1.1 package http.
Transfer-Encoding: chunked.
Accept-Encoding: gzip.
.
b.
First Chunk
#
T 127.0.0.1:52415 -> 127.0.0.1:8080 [AP]
.
c.
Second Chunk
#
T 127.0.0.1:52415 -> 127.0.0.1:8080 [AP]
.
0.
.

####
T 127.0.0.1:8080 -> 127.0.0.1:52415 [AP]
HTTP/1.1 200 OK.
Content-Length: 0.
.

######

What do you see instead?

The output from ngrep only contains a single TCP packet from the go process to the
server:

ngrep -W byline -d lo0 port 8080
interface: lo0 (127.0.0.0/255.0.0.0)
filter: (ip) and ( port 8080 )
#####
T 127.0.0.1:52641 -> 127.0.0.1:8080 [AP]
POST / HTTP/1.1.
Host: 127.0.0.1:8080.
User-Agent: Go 1.1 package http.
Transfer-Encoding: chunked.
Accept-Encoding: gzip.
.
b.
First Chunk.
c.
Second Chunk.
0.
.

##
T 127.0.0.1:8080 -> 127.0.0.1:52641 [AP]
HTTP/1.1 200 OK.
Content-Length: 0.
.

######

Which operating system are you using?

OSX

Which version are you using?  (run 'go version')

go version go1.1.2 darwin/amd64

Is there a known workaround for this issue?

No. There are several easy fixes. I'm debating which I like the most. I'll try to get one into 1.5.

Ok thanks. So I take it I can't do any workarounds for this that doesn't involve patching the stdlib then?
Currently I've devolved into shelling into curl to make tightly streamed text output work -- but looking forward to the fix.

There are no workarounds.

Awesome! I'll be sure to try HEAD if this gets merged in :)
On Wed, May 13, 2015 at 1:00 PM, GopherBot notifications@github.com wrote:

CL https://golang.org/cl/10021 mentions this issue.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/6574#issuecomment-101796687.

authors: benburkert bradfitz cyx


text:
x/vuln: is it possible check only the go.mod ?

Hello
sometimes, when I am trying to run govulncheck on a large codebase it can be OOMKilled
is it possible add an quick mode and verify only the go.mod ? It may give some hints and maybe give a faster answer

many existing tools do this and has proven to be too inaccurate to be generally useful

authors: peczenyj seankhliao


text:
jsonpb: Allow rendering extension field names without square brackets

Is your feature request related to a problem? Please describe.
Names of extension fields are rendered enclosed in square brackets. When serializing JSON we don't wish these fields to appear any different from non-extension fields.
This behavior is located here
Describe the solution you'd like
I'd like to add a boolean configuration option to the Marshaler struct that will by default continue to emit extension field names in brackets, and if configured otherwise will emit the name without brackets.
Describe alternatives you've considered
Since I am dealing with an extension object on a third-party proto definition I don't believe I can just implement JSONPBMarshaler.
Additional context
If this is confirmed to be something people are open to I can put up a PR with this change

The protobuf JSON specification lacks a formal definition of how proto2 extensions are handled, but the convention throughout the protobuf ecosystem is to serialize them with brackets. Go is not unique in handling them this way and the goal of the project is to maintain compatibility with other languages.
The usage of brackets has semantic purpose since it is what enables the parser to distinguish between a normal field and an extension without them, otherwise there'd be ambiguity. For that reason they can not be dropped.

Thank you for the insight, @dsnet !

authors: dsnet zdicesare

repo: golang/protobuf

license_source: bigquery


text:
do not allow files that cross package boundaries

protoc-gen-go tries to disallow multiple files if they cross package boundaries -- it wants to be invoked for a single package at a time, and with all files for that package at the same time.
But it doesn't do a very good job checking for this condition. It simply verifies that the package name for all files is the same, but it does not check that all files emit code to the same package path (which is what Go really considers to be the identity of a package).
That means I can supply different files that have the same package name but live in different folders, and the generated code is simply wrong. Because it assumes they are the same package (including same package path), references from one to the other will result in code that uses naked symbol references (no package qualifier/alias) and also not produce an import statement.
So this change will cause the plugin to issue an error message if the files it produces would be in different Go packages.

Ping?

This is reasonable, but I'm in the middle of some significant reworking of this part of the code. (I'd really like to make it possible to just generate output for multiple packages at once, but no promises.) Mind holding off for a bit?

@neild, I am happy to never merge this. I think protoc-gen-go's behavior that requires it to compile only one package and a complete package (e.g. can't produce output for single proto file at a time, if the target package results from more than one source file) is actually terrible. It is very different from how other language output works, where protoc happily transforms any number of files, regardless of package.
This patch was just to make that behavior actually work, since we ran into a situation where files had different packages, but the same name last path element. Instead of spitting out an error, the plugin just generated non-working code.
When I worked at Square, we (and by we I mean @zellyn) tried to submit issues/patches to fix that IIRC, but they weren't accepted. It required us to maintain a fork of this repo since we had build scripts that would generate code for lots of proto files (crossing packages) all at once, and generate output for multiple languages, not just Go (only Go has this quirk).

We use https://github.com/square/goprotowrap. It doesn't let you generate one file at a time, but it does help you generate all the files you need at once without having to think about it.
Back when I was working on Go at Square (I got reassigned to Java-land 😢), it seemed that a few fairly simple changes to how go protobufs generate code would fairly easily clean up the file-at-a-time restriction. In particular, uniquifying symbols better within each file would probably do it. (While you're at it, you might want to make package import names sane too…)
However, getting even simple patches (or indeed even ideas for changes: I'm fine if the maintainers don't like my implementation) against the Go protobuf code base accepted proved completely futile, and we gave up.

@zellyn Please bring your ideas.  This is a new team maintaining golang/protobuf.  They listen to ideas and are really trying to fix things.

@awalterschulze, I remember a couple of them. One of them is written up in #141.
The other was embedding the proto source file name into the fileDescriptor* names, instead of just a numeric suffix that always started at 0. That would allow compiling two source files for the same package in separate invocations of protoc and still getting deterministic output that compiles. (Currently, that produces code that won't compile because each output file will have a package-level var with the same name, like fileDescriptor0.)

Oh wow I remember that the fileDescriptor one.
I think gogoprotobuf ended up going for the filename instead of the number.
That was quite a while ago.

Heh. I forgot about #141. That is a pretty good writeup. Good work, past self! :-)

FYI, #549 will change protoc-gen-go to enforce that all generated files are under the same import path.
(I'm also making progress towards removing the need for that requirement entirely, but it's not there yet.)

source: gharchive/pull-request

authors: awalterschulze jhump neild zellyn


text:
Fortran error in compilation

amino fails to compile for me because of (I think) Fortran version errors.

With gfortran 5.4.1, 6.4.1, and 8.1.0 I get a large number of syntax errors while compiling src/la_implf.f90. They seem to stem from a line truncation/unterminated character constant at line 447. (note that I'm forcing the earlier versions of gfortran by running e.g. FC=gfortran-5 F77=gfortran-5 ./configure for gfortran 5.4.1.)

With f2c 12.02.01, I get an error that "mem_mod.f90 does not end in .f or .F" (note that I'm forcing f2c by running FC=f2c F77=f2c ./configure.)

I suspect that these errors are version related because I'm on Arch Linux, which tends to have newer versions than Xenial (the Travis environment). I've skimmed the Travis logs, and it seems you're using GCC 4.8.4 there. I would be a bit surprised if enough changed in gfortran between 4.8.4 and 5.4.1 to cause compilation to break, but I know very little about Fortran, so perhaps this is the case.
Do you have any suggestions for debugging my build? I have tried using ./configure --without-fortran, but this causes other errors - gcc: error: euler.c: No such file or directory.
My versions of each of the required dependencies are:

gcc: 8.1.0
gfortran or f2c versions: as above
maxima: 5.41.0
flex: 2.6.4

As an update, I compiled gcc 4.8.4 and tried using gfortran 4.8.4 in the same way as 5.4.1, etc. above. I get the same errors. This implies to me that there's some other configuration error with my system, but given that la_implf.f90 isn't dynamically generated by any part of the build (as far as I can tell), I'm not sure where to look.

Can you check what flags are being passed to gfortran?  You may need to run with make V=1.
It sounds like the flag to allow arbitrary line lengths may have changed.  But, if you reverted to gcc/gfortran 4.8.4, then it should work OK... Did you rerun ./configure after switching the gfortran version?
Alternatively, we can skip gfortran and use f2c.  Using f2c as a fortran90 compiler (FC) will probably fail, though, since I think f2c only does fortran77.  If you don't set the FC or F77 variables, and run ./configure --without-fortran, then the build scripts will omit the fortran90 sources and use f2c only for the fortran77 sources.
And it sounds like I ought to add Arch Linux to the integration tests.

Can you check what flags are being passed to gfortran? You may need to run with make V=1.

With make V=1:
/bin/sh ./libtool  --tag=FC   --mode=compile gfortran-4.8  -g -O2 -c -o la_mod.lo la_mod.f90
libtool: compile:  gfortran-4.8 -g -O2 -c la_mod.f90  -fPIC -o .libs/la_mod.o

Referencing the relevant line of the latest Travis build
/bin/bash ./libtool  --tag=FC   --mode=compile gfortran  -Wintrinsic-shadow -Wunused-parameter -Wtabs -Warray-temporaries -Wunderflow -Wimplicit-procedure -Wimplicit-interface -Wshadow -Wextra -pedantic -Wall -ffree-line-length-none -fimplicit-none -g -O2 -c -o la_mod.lo la_mod.f90

it looks like I may need to manually add back in the flags if I'm manually setting FC and F77. I could also try symlinking gfortran-4.8 to gfortran on my system as a hack to test if it's just a matter of missing flags.

It sounds like the flag to allow arbitrary line lengths may have changed. But, if you reverted to gcc/gfortran 4.8.4, then it should work OK... Did you rerun ./configure after switching the gfortran version?

I did rerun ./configure (I've actually been taking the unnecessarily drastic step of wiping out the repo and re-cloning every time I switch versions, just to make sure there's a totally clean environment. When I was using make clean between version switches, it seemed that some intermediate files stuck around).
However, I may have misread the error output from gfortran 4.8.4 when I first ran it - it is subtly different from what I get with later versions, and does not mention the line extension. I've copied the full error output here: https://gist.github.com/wbthomason/6673d68c3c95da4f477b18c6b5801150

Alternatively, we can skip gfortran and use f2c. Using f2c as a fortran90 compiler (FC) will probably fail, though, since I think f2c only does fortran77. If you don't set the FC or F77 variables, and run ./configure --without-fortran, then the build scripts will omit the fortran90 sources and use f2c only for the fortran77 sources.

I'd tried this before, unfortunately. I get the error:
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I./include -I./include -I./src/mac -g -O2 -MT euler.lo -MD -MP -MF .deps/euler.Tpo -c euler.c  -fPIC -DPIC -o .libs/euler.o
gcc: error: euler.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
make[2]: *** [Makefile:2795: euler.lo] Error 1

so it looks like something isn't being generated when it needs to be.

And it sounds like I ought to add Arch Linux to the integration tests.

I'd be happy to help with this if I can!
Sorry for all the trouble (my Fortran knowledge could fit in the empty set), and thank you for the help! I'm going to try manually specifying the missing feature flags and seeing if that works; I'll post the results back here.

Do you have the autoconf macro archive installed?
The build scripts use some of those macros to check which compiler flags are valid.  It looks like those checks aren't happening.

Well, adding the flags did get me past this particular error, and onto new and exciting errors trying to compile src/rx/mp/scene_ompl.cpp due to missing function calls to OMPL functions. During the configure stage, I get warnings that ompl/base/TypedSpaceInformation.h is "present but cannot be compiled" (and a request to report the warning to you). I suspect the new errors are related to this warning.

I did not have the autoconf macro archive installed. Installing that does also fix the Fortran error, though not the OMPL error (as expected).

Ok, progress!
Can you attach the config.log with the TypedSpaceInformation.h error?
(FYI, this check is to work with older versions of OMPL that don't include some templates for managing configuration spaces)

Here's the config.log. The relevant lines are 3150 - 3169. config.log
Here also are the errors I get when compiling:
ompl_errors.txt

Could you please apply the attached patch and re-make?
cloneState.patch.txt

Looks like newer GCC is stricter with templates.  The patch fixed an error that older GCC had ignored.
The other errors might come from ompl's change from boost::shared_ptr to std::shared_ptr.  What happens if you change every boost::shared_ptr to std::shared_ptr in ompl-compat/.../TypedSpaceInformation.h?

Interesting. That change does fix the OMPL errors. Now, however, SBCL complains about being unable to load LIBAMINO because it cannot open libamino.so while compiling tf-grovel.lisp.
I am using SBCL 1.4.6 vs the 1.3.1 on Travis. I'm more inclined to believe that this is a configuration error with my CL environment, though, so I'm going to play around with that and see if I can make things work.
Sorry about the cascading rabbit hole of errors here!

Seems like something is not getting compiled or linked correctly.
The function aa_tf_eulerzxy2rotmat_ is in the generated source file src/mac/euler.f (fortran appends an underscore to function symbols).  This file is either compiled with gfortran or translated with f2c and linked into libamino.  Are we missing one of these steps?

I think that particular error may have been caused by having both f2c and gfortran accessible on the PATH. Uninstalling f2c gets past that error, but breaks at a very similar error - now, the missing symbol is cblas_dnrm2, which ought to be from src/la.c. src/la.c does get compiled into src/.libs/la.o, which is linked into .libs/libamino.so.0.0.0 as it should be. None of these steps seem to report failure.
I've included the full output of make V=1; I'll keep poking through it in the morning to see if I'm just missing something. detailed_make.txt

Ok, cblas_dnrm2 is an external library function (part of the C API for BLAS, which is natively Fortran).  In Debian/Ubuntu, the CBLAS functions are in the same library as the Fortran BLAS functions.  Maybe Arch uses a separate library?

I've fixed the last remaining error. It was due to Arch weirdness, though not that particular Arch weirdness.
Possibly uninteresting detail follows:
Arch has packages cblas, which provides CBLAS, and blas and openblas, both of which provide an implementation of BLAS. I had cblas and openblas installed. The weirdness (or, rather, unexpected condition) from Arch is that openblas is configured to be linked against with -lopenblas rather than -lblas. This breaks pkg-config for cblas, as cblas is trying to link against BLAS with -lblas. This means that pkg-config --libs --cflags cblas will fail. I'm not sure if your autotools setup for amino uses pkg-config to find linker flags, but manually modifying the generated Makefile to include -lcblas in the LIBS variable did the trick and made everything happily compile.

To summarize this chain of errors when compiling on Arch:

It seems that versions of gfortran later than 4.8.4 have changed flag names and thus fail to enable the necessary Fortran extensions.
Arch doesn't include autoconf-archives with autoconf by default. Amino relies on these archives being present.
Newer gcc (8.1.0) is stricter with templates than 4.8.4, and thus throws errors on syntax that was permitted with 4.8.4. The first patch fixes this.
Use of Boost's shared_ptr type leads to an incomplete type error in TypedSpaceInformation.h. Replacing this with std::shared_ptr fixes the error.
Having f2c and gfortran in the PATH leads to f2c being used where it should not be, and causes undefined symbols in libamino.so. Uninstalling f2c fixes this.
By default, ./configure does not appear to link against CBLAS on Arch, possibly because of the aforementioned pkg-config brokenness. Manually editing the Makefile is a hacky fix for this; perhaps there's a better option? I will be filing a bug on the Arch openblas package, because it should provide blas.pc by default anyway.

With all of these fixes applied, make and sudo make install succeed. I haven't tried linking against libamino yet to confirm that everything is working, but there are at least no compile errors, and aarxc seems to run correctly.
Thank you very much for all the help! I look forward to using Amino. Please let me know if I can help with anything, or if you need more information or help reproducing one or more of these errors.

Great, glad we sorted this out.
Thank you for summarizing the necessary steps and changes.  I will update the integration tests when I return from ICRA.

I'm currently having this same issue, on Ubuntu Focal. I confirmed the autoconf macros are installed, as that seems to be a common issue.
When running with ./configure --without-fortran I can build fine, but if I try to run ./configure --without-fortran --enable-demos, I get the following error from make V=1:
/bin/bash ./libtool  --tag=CC   --mode=link gcc  -g -O2   -o aarx.core    -lnlopt -lglpk -lpthread -ldl -lm -llapack -lblas
libtool: link: gcc -g -O2 -o aarx.core  -lnlopt -lglpk -lpthread -ldl -lm -llapack -lblas
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/Scrt1.o: in function `_start':
(.text+0x24): undefined reference to `main'
collect2: error: ld returned 1 exit status

It sounds like I would need to install an old version of gfortran, but 4.8 is not available on the latest Ubuntu LTS. Is there another way?

authors: biotinker ndantam wbthomason

repo: golems/amino


text:
Use HTTP request for fetching data from Kamstrup 401

Did you read the instructions?

[X] I have read the README.

The request
I now use a ESP8266 to get data from Kamstrup401. With a URL i can fetch data from the ESP8266. The IR reader is connected to the ESP8266
Example : http://192.168.0.207/energy
The response is:  {"energy [GJ]" : 371.383,"power [kW]" : 0.0,"flow [l/h]" : 0,"water [m3]" : 27509.55,"tempin" : 29.48,"tempout" : 22.59,"tempdiff" : 6.89}
So it would be nice if this also can be used.
Additional information
No response

This is out of scope.
If you use an ESP to read the values from your meter, why not publish them to MQTT and let Home Assistant get them from there? Or when using ESPHome, you can publish the values directly into Home Assistant. In both these suggestions you can use push mechanisms instead of fetch, which is IMO always preferred.

Or perhaps you can use the rest integration for this.

Did you read the instructions?

[X] I have read the README.

The request
I now use a ESP8266 to get data from Kamstrup401. With a URL i can fetch data from the ESP8266. The IR reader is connected to the ESP8266
Example : http://192.168.0.207/energy
The response is:  {"energy [GJ]" : 371.383,"power [kW]" : 0.0,"flow [l/h]" : 0,"water [m3]" : 27509.55,"tempin" : 29.48,"tempout" : 22.59,"tempdiff" : 6.89}
So it would be nice if this also can be used.
Additional information
No response

Can you share the code for esp8266? I have multical 603 and would like esp to publish data into MQTT.

Did you read the instructions?

[x]  I have read the README.

The request
I now use a ESP8266 to get data from Kamstrup401. With a URL i can fetch data from the ESP8266. The IR reader is connected to the ESP8266
Example : http://192.168.0.207/energy
The response is:  {"energy [GJ]" : 371.383,"power [kW]" : 0.0,"flow [l/h]" : 0,"water [m3]" : 27509.55,"tempin" : 29.48,"tempout" : 22.59,"tempdiff" : 6.89}
So it would be nice if this also can be used.
Additional information
No response

Can you share the code for esp8266? I have multical 603 and would like esp to publish data into MQTT. Also the ir sensor is diy?

Sure, How can i contact you?

Could you create a repo at your github and be could talk about it there? It might also be possible to do a direct esphome version for usage in home assistant like home assistant glow.

Did you read the instructions?

[x]   I have read the README.

The request
I now use a ESP8266 to get data from Kamstrup401. With a URL i can fetch data from the ESP8266. The IR reader is connected to the ESP8266
Example : http://192.168.0.207/energy
The response is:  {"energy [GJ]" : 371.383,"power [kW]" : 0.0,"flow [l/h]" : 0,"water [m3]" : 27509.55,"tempin" : 29.48,"tempout" : 22.59,"tempdiff" : 6.89}
So it would be nice if this also can be used.
Additional information
No response

Can you share the code for esp8266? I have multical 603 and would like esp to publish data into MQTT. Also the ir sensor is diy?

Sure, How can i contact you?

Could you create a repo at your github and be could talk about it there? It might also be possible to do a direct esphome version for usage in home assistant like home assistant glow.

Did you read the instructions?

[x]   I have read the README.

The request
I now use a ESP8266 to get data from Kamstrup401. With a URL i can fetch data from the ESP8266. The IR reader is connected to the ESP8266
Example : http://192.168.0.207/energy
The response is:  {"energy [GJ]" : 371.383,"power [kW]" : 0.0,"flow [l/h]" : 0,"water [m3]" : 27509.55,"tempin" : 29.48,"tempout" : 22.59,"tempdiff" : 6.89}
So it would be nice if this also can be used.
Additional information
No response

Can you share the code for esp8266? I have multical 603 and would like esp to publish data into MQTT. Also the ir sensor is diy?

Sure, How can i contact you?
Can you also share the ESP8266 code with me? I am in a similar situation where the meter is nowhere near the RPi.

@vittrup88  Yes, the sensor is easy to make. I got a few PCBs from a user on tweakers.

With the latest release, this component is able to connect to a remote serial connection, see https://github.com/golles/ha-kamstrup_403/releases/tag/2.5.0

license: MIT


text:
If ARCore not installed, display a more specific message

Right now, if ARCore is not installed, running WebARonARCore just crash loops. Due to the naming similarity, it's easy to miss this step in the installation instructions. A message instead/before crashing that ARCore is required would be helpful

This issue will be resolved as soon as #38 lands.

authors: jsantell judax

repo: google-ar/WebARonARCore


text:
JAX problems

I am running the model using my own data read from ERA5, the dataset I am using to feed the model looks identical to the one stored on the google bucked.
The worked fine when I run it locally with the data used in the demo, but I am having problems with JAX when I run the model using my data.
I had this error message
TypeError: Argument 'dask.array<getitem, shape=(1, 2, 37, 721, 1440), dtype=float32, chunksize=(1, 2, 37, 721, 1440), chunktype=numpy.ndarray>' of type <class 'dask.array.core.Array'> is not a valid JAX type.
Anyone had the same problem?

I think this may be fixed by calling ".compute()" on all of the data (inputs, targets and forcings), before passing it to the model.

authors: agbruno-git alvarosg

repo: google-deepmind/graphcast


text:
ValueError: All hk.Modules must be initialized inside an hk.transform

I followed all of the instructions titled "Live Demo" of README.md, including the installation of dependencies, and updating the PYTHONPATH.
However, I get the following error when I run python3 ./tapnet/live_demo.py
  File "[...]/tapnet/live_demo.py", line 38, in <module>
    tapir = tapir_model.TAPIR(
  File "[...]/.local/lib/python3.10/site-packages/haiku/_src/module.py", line 139, in __call__
    init(module, *args, **kwargs)
  File "{[...]/.local}/lib/python3.10/site-packages/haiku/_src/module.py", line 433, in wrapped
    raise ValueError(
ValueError: All `hk.Module`s must be initialized inside an `hk.transform`.

i'm facing the same issue. Have you fix it?

Yup, forgot that even the tapir constructor needs to be called inside a haiku transform.  I've attached a working verson of this script, but it's a bit ugly; we may need to work on simplifying this further.
live_demo.zip

Yup, forgot that even the tapir constructor needs to be called inside a haiku transform. I've attached a working verson of this script, but it's a bit ugly; we may need to work on simplifying this further. live_demo.zip

Hi, your work is pretty good. But when I try to modify your code, I found the performance decreased a lot.
First, I loaded a video, and put the query frame(from another video) as the first frame of the tracked video(synthesis the query frame and the video to be tracked as a single video). Then I put the synthetic video into the online model(include the query frame as the first frame). However, the performance was not good especially at the first few frames. I guess that the reason is that the query frame from another video has a large gap with the video I'd like to track(it is also officially recommanded to use video more than 12 fps, maybe the performance will decrease when two neighboring frames have a large gap). Could you tell me the reason why performance decreased or it's just other details(my code framework is right)?
I also try another way. I first load the query frame and modify your compliation part as the part to get the query feature. and then reinit the causal state. and then track these points on the video. Is this right?
I 'm new in haiku and other packages. I wonder if it's necessary to learn the haiku, tensorflow,  jax and other packages.
Very grateful.

Yes, if you want to track across videos, we recommend that you have separate forward passes to extract features and to perform tracking; the model hasn't seen cuts during training, so it tends to get confused by them.
That said, these results look extremely jittery.  What points are you trying to track?  The model will always struggle to track textureless regions, but it should do OK for points on the objects.  I suspect there's something wrong with the way you're using the causal state, but it's hard to say without seeing the code.
(FYI, we're hoping to release a better version of this interface in the next few days, as soon as I get around to updating our colabs)

Yes, if you want to track across videos, we recommend that you have separate forward passes to extract features and to perform tracking; the model hasn't seen cuts during training, so it tends to get confused by them.
That said, these results look extremely jittery. What points are you trying to track? The model will always struggle to track textureless regions, but it should do OK for points on the objects. I suspect there's something wrong with the way you're using the causal state, but it's hard to say without seeing the code.
(FYI, we're hoping to release a better version of this interface in the next few days, as soon as I get around to updating our colabs)

The points I try to track are seven active points got from two demos(six of them are on the red cube which is going to be grasped). As you say, the problem of my video is maybe the causal state. So I try to separate the two parts. Below is my detail, do you think my thought is right?
I try to use causal_state = hk.transform_with_state(lambda : tapir().construct_initial_causal_state(       NUM_POINTS, len(query_features.resolutions) - 1   )).apply(params=params, state=state, rng=rng)[0] to init causal state after get query feature from query frame. And then I try to track query points on my camera(maybe this separate the query frame and the video to be tracked).The result gets better. But there's still a gap between my result and your result shown in https://robotap.github.io/
I‘m grateful to see your update of the online version.

Yes, if you want to track across videos, we recommend that you have separate forward passes to extract features and to perform tracking; the model hasn't seen cuts during training, so it tends to get confused by them.
That said, these results look extremely jittery. What points are you trying to track? The model will always struggle to track textureless regions, but it should do OK for points on the objects. I suspect there's something wrong with the way you're using the causal state, but it's hard to say without seeing the code.
(FYI, we're hoping to release a better version of this interface in the next few days, as soon as I get around to updating our colabs)
This is a demo video which has the seven active points.

https://github.com/google-deepmind/tapnet/assets/110964890/3f207f3d-4188-44ff-b24f-b7cf6e04bc5b
Here is my video which separate the two parts(get query feature part and online track part). The blue points are active demo points and the red points are active points to be tracked online. You can ignore the green and blue arrows(I use them for debug)
https://github.com/google-deepmind/tapnet/assets/110964890/75baf105-1648-4e28-8c85-21eb737318da

The tracks on your demo look pretty reasonable to me, which suggests you're using the code correctly.
It looks like the objects are oriented differently between the demo video and the test-time video. This is a known weakness of TAPIR--there's relatively little in-plane rotation in Kubric, so the model doesn't have very good invariance to it. Also, are you re-using textures across different objects? This may cause problems as well (TAPIR may have spurious matches on the wrong object). In real videos, stochastic textures like wood grain are unlikely to repeat exactly. I expect BootsTAP will improve on both of these; we hope to release a causal BootsTAPIR model sometime in the next few weeks. However, it may not completely solve these problems.
Also, are you plotting occluded points in the test-time video? I'd like to see a version where you don't do this; TAPIR shouldn't be marking those points as visible since they're obviously wrong.

What's more, I find tapir spends more than half an hour to inference a video having only 500 frames?(online version is much faster) I don't know the reason(maybe because I can't use parallel compilation, but I 'm not sure) . could you tell me how to solve the problem?Thanks

The original bug about "All hk.Modules must be initialized inside an hk.transform" in live_demo.py should be fixed with the latest push.
Unfortunately this push also includes the update that replaces the deprecated jax.tree_map with the very recently-introduced jax.tree.map, so the codebase now requires a very recent version of jax in order to run.  It should be safe to do a find/replace with jax.tree_map to be compatible with older versions; we aren't using any other new jax features.

authors: Air1000thsummer cdoersch mysticalfirellama nutsintheshell

repo: google-deepmind/tapnet


text:
Kotlin Playground Empty & not editable

URL of codelab
https://developer.android.com/training/kotlinplayground
In which task and step of the codelab can this issue be found?

Create a base class, item1

Describe the problem
The Kotlin playground can't be edited. No codes are available on the link.
Steps to reproduce?

Go to Kotlin Basic
Click on Module 2
Click on Create a Base class
See item 1
Click the link directing to Kotlin playground
See error

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

@ralph-embalsado
Thank you for reaching out to us.
The link given in the codelab is correct: https://developer.android.com/training/kotlinplayground
Try changing the code inside the code block.

There won't be any code in the playground, you need to copy-paste from the codelab.
Alternatively you can use the following Kotlin playground:
https://play.kotlinlang.org/
If you still face issues please send in the screenshots.

The issue is closed as no further clarification of it was provided.

authors: jtavva osuleymanova ralph-embalsado


text:
RawGooglePayButton requires a PaymentConfiguration

RawGooglePayButton requires PaymentConfiguration but this doesn't allow us to use flutter_pay's Pay client effectively.

Can you elaborate on that @JudahMcNicholl?
The RawGooglePayButton now uses the PayButton API for Google Pay, which requires initialization parameters from the configuration. (see https://developers.google.com/pay/api/android/guides/resources/pay-button-api).

authors: JlUgia JudahMcNicholl

repo: google-pay/flutter-plugin


text:
usage of the checkpoint throws error

I want to evaluate axial-deep lab.
Here is my cmd:
train.py
--config_file
../configs/cityscapes/axial_deeplab/max_deeplab_s_backbone_os16.textproto
--mode
eval
--model_dir
C:\develop\max_deeplab_s_backbone_os16_axial_deeplab_cityscapes_trainfine\
I also updated initial_checkpoint to C:\develop\max_deeplab_s_backbone_os16_axial_deeplab_cityscapes_trainfine\ckpt-60000, which is the prefix for both the data and index file downloaded from the official checkpoint.
when I run the script, i keep getting a warning:
WARNING:tensorflow:Unresolved object in checkpoint: (root).optimizer
W0201 20:33:08.415140 51764 util.py:204] Unresolved object in checkpoint: (root).optimizer
....
The dataset pattern and experiment name are correct I believe since there isn't error in previous stages, but only when the evaluation starts.
Am I using the checkpoint int a wrong way? I am confused by checkpath path, which could be a dir, or one of the files(data, index), or it could be dir/ckpt-60000?

Hi @posEdgeOfLife
Could you provide us some more information about the following:

Your OS
Python version
Tensorflow version
Does the evaluation still run besides these warnings?

Hi @posEdgeOfLife
Could you provide us some more information about the following:

Windows 10
3.6.9
tf2.7
Yes, it would run with these warnings.

However, when I try to freeze the graph using the following:
model = tf.keras.models.load_model(r"C:/develop/max_deeplab_l_backbone_os16_axial_deeplab_cityscapes_trainfine_saved_model/")
 signatures = model.signatures['serving_default']
 frozen_func = convert_variables_to_constants_v2(signatures)

I got error:
ValueError: Node 'DeepLab/max_deeplab_l_backbone/stage4/block2/attention/height_axis/query_rpe/Gather/axis' is not unique
With a little debug, I found all gather nodes are converted from resourceGather which has two inputs:

resource
indices

These two are both converted to gather node with the same name. I am not sure what is a proper way to resolve this. Any suggestions? Thanks for help.

Hello,
Thanks for your interest in our work and the code.

WARNING:tensorflow:Unresolved object in checkpoint: (root).optimizer
W0201 20:33:08.415140 51764 util.py:204] Unresolved object in checkpoint: (root).optimizer

This warning looks normal to me. -- For evaluation, only model weights are useful. The optimizer states are not useful and thus are not loaded from the checkpoint file (which contains both model weights and optimizer states). So please disregard the warning, especially as you replied that your code is able to run with these warnings, but please make sure that the evaluation result matches the expected number.

Am I using the checkpoint int a wrong way? I am confused by checkpath path, which could be a dir, or one of the files(data, index), or it could be dir/ckpt-60000?

I think you are using it correctly. The checkpoint loader is designed in a flexible way (supports a file or a directory) so that we can load not only trained weights for evaluation, but also ImageNet pretrained checkpoints, as well as online evaluation of the lastest checkpoint in a directory while training.

ValueError: Node 'DeepLab/max_deeplab_l_backbone/stage4/block2/attention/height_axis/query_rpe/Gather/axis' is not unique

I have not seen such an error before. What are you trying to achieve with the frozen graph? Is it for model exporting/deployment? Does the frozen graph relate to the warning for evaluation mentioned in this issue?
Best,
Huiyu

Hi Huiyu, thanks for your answer. I figured out the checkpoint and the warning message(not clear when reading the documents), however, the last error is still not clear to me what is the root cause. Yes, i am trying to export the graph to some other formats, onnx mainly. The issue occurs when tensorflow convert resourceGather to a frozen node, it actually creates two nodes with the same name since resourceGather in this case has two inputs as its edge.  I slightly modified the tensorflow python code with a map for deduplication, but i am not super clear about the root cause.

Hi, glad to know that the checkpoint issue is resolved. I am not an expert in exporting graphs so I am not certain what the root cause is, but there are three points that may be helpful.

For Axial-DeepLab models, recompute_grad is usually set to True, and recompute_grad usually computes the forward pass for the second time during the backward pass. So I would suggest making sure that recompute_grad is disabled during exporting.
To figure out the root cause, maybe one can try exporting a ResNet model instead. The ResNet model will usually have recompute_grad disabled and will not use any relative positional encodings that call the gather function.
For Axial-DeepLab models, if the gathering nodes are the only issue that blocks the process, I believe the gathering node can be removed by simply storing the gathered output as model parameters. (The gather nodes in the relative positional encoding layers do not depend on the input image.)
That said, were you able to make it work with your deduplication modification?

Hi, glad to know that the checkpoint issue is resolved. I am not an expert in exporting graphs so I am not certain what the root cause is, but there are three points that may be helpful.

For Axial-DeepLab models, recompute_grad is usually set to True, and recompute_grad usually computes the forward pass for the second time during the backward pass. So I would suggest making sure that recompute_grad is disabled during exporting.
To figure out the root cause, maybe one can try exporting a ResNet model instead. The ResNet model will usually have recompute_grad disabled and will not use any relative positional encodings that call the gather function.
For Axial-DeepLab models, if the gathering nodes are the only issue that blocks the process, I believe the gathering node can be removed by simply storing the gathered output as model parameters. (The gather nodes in the relative positional encoding layers do not depend on the input image.)

That said, were you able to make it work with your deduplication modification?

Thanks again for the tips. Deduplication got me around the first issue, but I have to remove the post processing part out to eliminate loops, which is not supported in ONNX or tflite. However, after tested with onnxRuntime, the final result is not matching.  I got hang there since debugging layer wise is a lot of work. I think all 3 points you mentioned worth a retry to see if it fixes anything. Thanks again!

Hi @csrhddlam
I am trying to export a coco panoptic deeplab semantic segmentation  model with a resent beta backbone to a saved_model file. (can I/should I export to something else?)
I'm using the 60k checkpoint, I get several warnings but the export is done without errors (although nothing is created in saved_model/assets). The saved_model does not work as well as the eval step of the 60k checkpoint on the same image so I assume that the export isn't working great.
So first, If I want to export this checkpoint into a model that will eventually be used in C++, is there anything different I can do?
I noticed that resnet_beta has  'axial_use_recompute_grad' set to True, how can I set it to false? Under which category of the config file it should go?
Thanks!

OK, I partly answered myself. In order to change the setting it needs to be changed in the model/encoder/axial_resnet_instances.py    file.
I still have an issue so I'll open a new issue.

Closing the issue, since @fschvart has opened a new one, and @posEdgeOfLife could reopen it if there is still any issue.

authors: aquariusjay csrhddlam fschvart markweberdev posEdgeOfLife


text:
Bert vs Electra performances

Hello,
I am trying to compare the time performances of Bert and Electra pre-training.
Looking at the paper it seems that at fixed FLOPs (i.e. fixed time) electra performances are the best in downstreaming finetuning tasks.
I am struggling a bit with the comparison since the pre-training tasks are pretty different between the models and then I am not sure they can be directly compared by keeping the same hyper-parameters.
For instance:
max_seq_len used by Bert seems to stand for the total length of the couple of sentences while
for Electra is just one sentence,
this would suggest to half the length for Electra (or double for Bert), am I right?
On the other hand, if I do so, then the number of masks (or replacement in Electra) would be smaller since it scales as masked_lm_prob*max_seq_len.
Are there other parameters I should keep into account for this comparison?
I am keeping the number of steps to be the same all the time so I would expect an increased performance in finetuning tasks after electra pretraining.
As usual, any comment or help is really appreciated!

Hi! There can be multiple sentences in a max_seq_len example for ELECTRA as well. If it helps, I added the script we used for computing pre-training FLOPs here.

authors: clarkkev pretidav

repo: google-research/electra


text:
Different result in colab vs locally run jupyter notebook (IndexError: list index out of range in local)

Hello, I am facing a rather strange issue. I was running the wtq_predictions in Colab, where it worked well. When I am trying to reproduce the same result by running the notebook in my local machine, the answers are vehemently different.
For colab:

When I am trying to run the same code, in my Jupyter notebook, the result is as follows:

I get the following error:
---> 1 my_result = predict (updated_table,['What is the maximum sofa?', 'What is the icu_readm corresponding to the highest sofa?', 'What is the icu_readm corresponding to the lowest sofa?'] )
 in predict(table, queries)
69       print ('coordinates is: ', coordinates)
70       all_coordinates.append(coordinates)
---> 71       answers = ', '.join([table[row + 1][col] for row, col in coordinates])
72       position = int(row['position'])
73       aggregation = aggregation_to_string(int(row["pred_aggr"]))
 in (.0)
69       print ('coordinates is: ', coordinates)
70       all_coordinates.append(coordinates)
---> 71       answers = ', '.join([table[row + 1][col] for row, col in coordinates])
72       position = int(row['position'])
73       aggregation = aggregation_to_string(int(row["pred_aggr"]))
IndexError: list index out of range
As you can see, I printed out the row and column co-ordinates to check and they are wildly different in both cases.  There is a python version mismatch in Colab and my jupyter kernel. The colab runs with Python 3.7.10 and my kernel Python 3.6.13. I am running this is Ubuntu 16.04.
Any tips will be most appreciated. Thank you.

Hello @eisenjulian and @muelletm, any update on this? Thank you.

Hello @sbhttchryy ,
Sorry for the delay. One thing confusing me besides the inconsistent predictions is that in theory the model should never output a prediction coordinate that is out of bounds to the table. This is due to the logic here: https://github.com/google-research/tapas/blob/master/tapas/experiments/prediction_utils.py#L304-L305 that only gets the score for valid cells in the table. Give that, I have the following ideas/suggestions to try:

Perhaps the prediction is not actually running due to some other error and you are reading the predictions of an old output file: results/wtq/model/test.tsv try deleting the file before re-running
Check for a file named error in the execution path of the notebook, since it will contain any errors in the prediction loop
If you can, also try running locally from python 3.7 or 3.8 environment to validate if that's the issue
Confirm whether you are running locally with an installation from pypi or from the latest github clone (with pip install -e). If it's the latter, you could try adding some logs in prediction_utils in the lines I references to check the size of the input table there

Thanks a lot for the report!

authors: eisenjulian sbhttchryy

repo: google-research/tapas


text:
GIDSignIn.sharedInstance.restorePreviousSignIn() sometimes fails to invoke completion handler

Describe the bug
GIDSignIn.sharedInstance.restorePreviousSignIn() does not always invoke the completion handler.
I suspect these two closed issues may have the same root cause:

https://github.com/google/GoogleSignIn-iOS/issues/360
https://github.com/google/GoogleSignIn-iOS/issues/378

To Reproduce
There appears to be two requirements to reproduce this:

restorePreviousSignIn() must be invoked multiple times before the first call completes
the tokens must be close enough to expiring to trigger refresh logic

Specific repro steps:

Make local changes to DaysUntilBirthday sample app such that restorePreviousSignIn() is invoked twice - see:
https://github.com/google/GoogleSignIn-iOS/commit/01d8cb32d1315cea141feeed5c055c9beb912561
Sign in
Kill and restart the app. Check console: should see output below, indicating that both completion blocks are invoked:
0: Restoring
1: Restoring
0: Done: Optional(<GIDGoogleUser: 0x600002124820>), nil
1: Done: Optional(<GIDGoogleUser: 0x600002124820>), nil
Kill the app and wait for about an hour. I was also able to reproduce immediately by changing kMinimalTimeToExpire and kMinimumRestoredAccessTokenTimeToExpire to both be 60.0*59.9.
Restart the app and check console output.

Expected behavior
console output should be the following, indicating that both completion blocks were invoked:
0: Restoring
1: Restoring
0: Done: Optional(<GIDGoogleUser: 0x600002124820>), nil
1: Done: Optional(<GIDGoogleUser: 0x600002124820>), nil
Actual behavior
console output is the following, indicating the first completion block was not invoked:
0: Restoring
1: Restoring
1: Done: Optional(<GIDGoogleUser: 0x600002124820>), nil

Hi, you can check out this workaround. It's pretty ugly, but does the job.
https://github.com/google/GoogleSignIn-iOS/issues/378#issuecomment-2548475930

authors: Ariandr jonmindtrip

repo: google/GoogleSignIn-iOS


text:
Adds the PRPL pattern to /web

Fixes #3459
Notes:

Initially ported from https://www.polymer-project.org/1.0/toolbox/server
Added an Introduction that sets the stage for why PRPL is needed
Generalized prose to suggest it could be accomplished using other libraries/tools (Polymer App Toolbox is just an excellent example of how to achieve this)
Added call outs to check out the Shop demo and a Timeline breakdown over remote-debugging of the key performance moments to keep an eye on
Added conclusion with thoughts on the need for architectures that focus on interactivity
Added link to Kevin's talk and an experimental label near the top (as previously discussed)
Pete: intentionally didn't hook this up to the nav yet. Assumed we would do similar to #3525.

Reviewers:
Messaging: @graynorton @tjsavage @slightlyoff
/web inclusion: @petele

Per a Hangouts conversation with @addyosmani just now, I'm going to dust off a draft I started a couple of weeks ago and share it as an alternative take by tomorrow morning.

@addyosmani / @graynorton - Please assign to me when this is ready to go.

Sounds good. @graynorton Please feel free to grab me anytime and we can work on refining a take on this for /web together.

@petele I've reworked and significantly trimmed the introduction to the PRPL doc with Gray's help and this should hopefully be in a better place now. Any help with edits in order to land this would be 🎉

Honest question. Why is this not in /web/fundamentals/performance?

Because we're not quite ready with /web/fund/pwa, I'm going to hold this for today.

Not under performance as we didn't want to pitch it as best practice just
yet. Anything I can do on helping wrap up /pwa?
On Fri, Sep 30, 2016 at 6:47 AM Pete LePage notifications@github.com
wrote:

Because we're not quite ready with /web/fund/pwa, I'm going to hold this
for today.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/google/WebFundamentals/pull/3536#issuecomment-250748452,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGxaeUWIOipo-cdeP_UtEmzmL8CN9Jqks5qvRLsgaJpZM4KJPzf
.

After talking to Pete, this will go under performance.

🎉

authors: PaulKinlan addyosmani graynorton petele

repo: google/WebFundamentals


text:
New in Chrome 83 post

What's changed, or what was fixed?

adds New in Chrome 83 post

Whoops!
There were 2 warnings that will prevent this PR from being merged. Please take a look, and either fix, or provide a justification for why they can't be fixed.
WARNINGS
src/content/en/updates/2020/05/nic83.md#L8 - Common typo found: 'chrome' Should it be 'Chrome'?
src/content/en/updates/images/2020/05/forms-focus-ring.gif - Try to keep files below 500K, was 601K

authors: WebFundBot petele


text:
upstream examples to gee docs

It would be great if examples are upstreamed to the google earth docs.
For example, there is could be a new python tab in https://developers.google.com/earth-engine/guides/scale#code-editor-javascript using xee
Or there could be some integration with with the current python (geemap) examples https://developers.google.com/earth-engine/datasets/catalog/LANDSAT_LC08_C02_T1_TOA#colab-python-sample

@raybellwaves thanks for the suggestions!
More examples are in our plans. At this point I don't think they'll be included in https://developers.google.com/earth-engine pages. It will more likely be something independent like a Read the Docs site.

Closing as "planned docs enhancement"

authors: jdbcode raybellwaves

repo: google/Xee


text:
Getting Authorization Error on browser

When I run project with specified command:   python main.py --project_id='my-proj-id'
It spits out a url to paste to in browser for authentication. When I paste the URL on browser, I get following error:
Error 400: redirect_uri_mismatch
The redirect URI in the request, urn:ietf:wg:oauth:2.0:oob, can only be used by a Client ID for native application. It is not allowed for the WEB client type. You can create a Client ID for native application at https://console.developers.google.com/apis/credentials/oauthclient

I generated the oAuth credentials for web application. Can you please tell what do I need to setup to make this code work?

Please generate the OAuth Credentials for a "Desktop app" instead. Refer to this Support page for more information.

Please generate the OAuth Credentials for a "Desktop app" instead. Refer to this Support page for more information.


text:
Clear action does not move blocks to the trash

User should be able to retrieve old blocks, regardless of how they are deleted.

Got the following error when running:
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.google.blockly.demo, PID: 24858
java.lang.NullPointerException: Attempt to invoke virtual method 'com.google.blockly.android.TrashFragment com.google.blockly.android.control.BlocklyController.getTrashFragment()' on a null object reference
at com.google.blockly.android.ui.CategoryTabs.onCategoryClicked(CategoryTabs.java:231)
at com.google.blockly.android.ui.CategoryTabs.access$200(CategoryTabs.java:51)
at com.google.blockly.android.ui.CategoryTabs$CategoryAdapter$1.onClick(CategoryTabs.java:309)
at android.view.View.performClick(View.java:5637)
at android.view.View$PerformClick.run(View.java:22429)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)

This is quite old. Is it still something you want? The clear button current removes everything from the workspace and the trash. So would the expected behaviour of clear be to empty the trash, and then move the workspace into it?

I think there are reasons to consider both options for different applications. It's probably a good idea to have both a resetWorkspace() and a trashAllBlocks() on the BlocklyController, making it relatively trivial for developers to choose either.  At the moment, my only preference for reseting is because it is already implemented and working.

Fixed in #476.

authors: AnmAtAnm ChrisA89 adamlinscott

repo: google/blockly-android


text:
Question regarding the innovation record

Hey, I was wondering whether you actually used the data written to the innovation record at some point. In the current implementation it looks like you are just using it as a counter (and in a doc-string it is noted, that it might be used for checking whether an edge with the same node pair (src, dest) already exists. For getting a new node/edge id count from itertools could be used. For checking whether the node pair exists, a native python set might be more efficient.
Since the innovation record also stores whether a new node was generated and in which generation the innovation first occurred - it seems like you were planning to use that information somehow, but I can't reference in the code itself.
Did you use the information during debugging and analysis of executed experiments? If so, how did you utilize it?

Hey, for WANNs I did not. The innovation numbers are only used for crossover (which I didn't used) and speciation (which I didn't use).
The ordering can be used in NEAT to set different coefficients for 'compatibility distance', so that when comparing two networks you can set different distances between networks if the different genes are older or younger (comparing to a direct ancestor might be closer than comparing to a cousin). In practice I don't know if I've ever seen anybody set them different -- it is an interesting idea, but with all of the hyperparameters already in NEAT we really don't need any more.

Yep, that makes sense. Thanks for the answer.

authors: agaier plonerma

repo: google/brain-tokyo-workshop


text:
fix: include HTML and JS assets in wheel

At the momentvisualizer is not in the wheel, this causes an error when you want to render html using brax.v2.io.html.render_from_json which by default makes use of HTML and JS assets found within the visualizer folder.
import jax.random
import brax.v2.io.html
import brax.v2.envs

env = brax.v2.envs.ant.Ant()
brax.v2.io.html.render(env.sys, [env.reset(jax.random.PRNGKey(0)).pipeline_state])

Raises:
FileNotFoundError: [Errno 2] No such file or directory: '<REDACTED>/venv/lib/python3.10/site-packages/brax/v2/visualizer/index.html'

Because of:
html_path = epath.resource_path('brax') / 'v2/visualizer/index.html'

Which is not contained in the wheel.
Now a simple solution would be to include the files in visualizer in the wheel but I think you guys should consider moving the HTML and JS assets to possibly io because currently io and visualizer depend on each other, whether for Python code or HTML and JS assets.
I am happy to make an MR that moves the assets to brax.v2.io and make sure the assets are added to the distributable but please let me know what you would like to do.
Have a good weekend,
Cemlyn

Hi @cemlyn007 thanks for pointing this out! We added those files to the manifest so should be ok now

repo: google/brax


text:
Fixed layout issues with the capture FAB in the demo

Pictures of the issue:

**(when using 3:2 and 16:9 aspect ratios on the Nexus 5)
Pictures with the fix:

**(when using 3:2 and 16:9 aspect ratios on the Nexus 5)

Can you reformat the code?

@yaraki Can you provide more details on what should be changed?
(For example, should the Runnable inside repositionCaptureFab() be global?)

On Android Studio,
Win/Linux: Ctrl + Alt + L
Mac: Option + Command + L

authors: Alec-DeSouza yaraki

repo: google/cameraview


text:
Cron job /cron/group_sync is causing NotImplementedError

I don't understand this part. The cron job /cron/group_sync is turned on but the actually method is not implemented, which causes NotImplementedError.
I think if it's not implemented yet, it' better to turn off the cron job.
Because, for now, it is has errors log every 60 minutes in the App Engine.

Valid.  Thanks for the report!
https://github.com/google/cauliflowervest/commit/251874e1a517d67a56d9b5a809fde60a4109bab0

authors: cheonhyangzhang juofmgoblue

repo: google/cauliflowervest


text:
Python precerts scanner: Allow specifying start index.

This allows finding "recent" precerts.

That's the kind of pull request I like. :smiley:
LGTM

authors: eranmes pphaneuf

repo: google/certificate-transparency


text:
Don't emit StorageImageReadWithoutFormat

The only image read operation performed is OpImageSampleExplicitLod,
so there is no need to declare the StorageImageReadWithoutFormat
capability.
Fixes https://github.com/google/clspv/issues/5

I couldn't work out from the issue - but in theory would we need this again in future if we tried to implement all the OpenCL image builtins?

Yes, if we end up emitting an OpImageRead instruction.  But it should be conditional on the finer-grain test if that specific operation is used.
I haven't reviewed the full list of OpenCL image builtins to know.

Ok cool! Ship it 👍

Thanks for the review.
Passes on Release and Debug builds.

Pushed into master as https://github.com/google/clspv/commit/565571c385801d97f1c68a59ff6d0c58f61eaa50

repo: google/clspv


text:
Move to w3c_clipboardevent.js included within the closure repository

The closure externs have evolved since the externs were copied to
Elemental2 and the generated code will change as a result of this commit.
However it is unclear whether this will impact any downstream java code
bases but it seems unlikely.

Equivalent commit landed as https://github.com/google/elemental2/commit/a89a855e1a8470cd5076646a2bba3dc7bd4f0649


text:
-Xep:FieldMissingNullable:ERROR throws NPE

public class CallStatsAspect {     private final Logger logger = LoggerFactory.getLogger(getClass()); }
`Prone static analysis plugin.
private final Logger logger = LoggerFactory.getLogger(getClass());
^
Please report this at https://github.com/google/error-prone/issues/new and include the following:
 error-prone version: 2.1.0
 Stack Trace:
 java.lang.NullPointerException
at com.sun.tools.javac.code.Types.instance(Types.java:104)
at com.google.errorprone.dataflow.nullnesspropagation.NullnessPropagationTransfer.visitMethodInvocation(NullnessPropagationTransfer.java:485)
at com.google.errorprone.dataflow.nullnesspropagation.AbstractNullnessPropagationTransfer.visitMethodInvocation(AbstractNullnessPropagationTransfer.java:303)
at com.google.errorprone.dataflow.nullnesspropagation.AbstractNullnessPropagationTransfer.visitMethodInvocation(AbstractNullnessPropagationTransfer.java:126)
at org.checkerframework.dataflow.cfg.node.MethodInvocationNode.accept(MethodInvocationNode.java:79)
at org.checkerframework.dataflow.analysis.Analysis.callTransferFunction(Analysis.java:404)
at org.checkerframework.dataflow.analysis.Analysis.performAnalysis(Analysis.java:225)
at com.google.errorprone.dataflow.nullnesspropagation.TrustingNullnessAnalysis.getFieldInitializerNullness(TrustingNullnessAnalysis.java:115)
at com.google.errorprone.bugpatterns.nullness.FieldMissingNullable.matchVariable(FieldMissingNullable.java:89)
at com.google.errorprone.scanner.ErrorProneScanner.visitVariable(ErrorProneScanner.java:1150)
at com.google.errorprone.scanner.ErrorProneScanner.visitVariable(ErrorProneScanner.java:146)
at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:968)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
at com.google.errorprone.scanner.Scanner.scan(Scanner.java:82)
at com.google.errorprone.scanner.Scanner.scan(Scanner.java:42)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:113)
at com.sun.source.util.TreeScanner.visitClass(TreeScanner.java:187)
at com.google.errorprone.scanner.ErrorProneScanner.visitClass(ErrorProneScanner.java:590)
at com.google.errorprone.scanner.ErrorProneScanner.visitClass(ErrorProneScanner.java:146)
at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:808)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:82)
at com.google.errorprone.scanner.Scanner.scan(Scanner.java:82)
at com.google.errorprone.scanner.Scanner.scan(Scanner.java:42)
at com.sun.source.util.TreeScanner.scan(TreeScanner.java:105)
at com.sun.source.util.TreeScanner.scanAndReduce(TreeScanner.java:113)
at com.sun.source.util.TreeScanner.visitCompilationUnit(TreeScanner.java:144)
at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:605)
at com.google.errorprone.scanner.ErrorProneScanner.visitCompilationUnit(ErrorProneScanner.java:146)
at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept(JCTree.java:591)
at com.sun.source.util.TreePathScanner.scan(TreePathScanner.java:56)
at com.google.errorprone.scanner.Scanner.scan(Scanner.java:64)
at com.google.errorprone.scanner.ErrorProneScannerTransformer.apply(ErrorProneScannerTransformer.java:41)
at com.google.errorprone.ErrorProneAnalyzer.finished(ErrorProneAnalyzer.java:145)
at com.sun.tools.javac.api.MultiTaskListener.finished(MultiTaskListener.java:120)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1425)
at com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1374)
at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
at com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:100)
at com.sun.tools.javac.api.JavacTaskImpl.handleExceptions(JavacTaskImpl.java:142)
at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:96)
at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:90)
at com.google.errorprone.BaseErrorProneCompiler.run(BaseErrorProneCompiler.java:137)
at com.google.errorprone.BaseErrorProneCompiler.run(BaseErrorProneCompiler.java:108)
at com.google.errorprone.ErrorProneCompiler.run(ErrorProneCompiler.java:118)
at com.google.errorprone.ErrorProneCompiler.compile(ErrorProneCompiler.java:65)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at net.ltgt.gradle.errorprone.ErrorProneCompiler.execute(ErrorProneCompiler.java:63)
at net.ltgt.gradle.errorprone.ErrorProneCompiler.execute(ErrorProneCompiler.java:24)
at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.delegateAndHandleErrors(NormalizingJavaCompiler.java:99)
at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:52)
at org.gradle.api.internal.tasks.compile.NormalizingJavaCompiler.execute(NormalizingJavaCompiler.java:37)
at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:35)
at org.gradle.api.internal.tasks.compile.CleaningJavaCompilerSupport.execute(CleaningJavaCompilerSupport.java:25)
at org.gradle.api.tasks.compile.JavaCompile.performCompilation(JavaCompile.java:209)
at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:190)
at org.gradle.api.tasks.compile.JavaCompile.compile(JavaCompile.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$IncrementalTaskAction.doExecute(DefaultTaskClassInfoStore.java:163)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:134)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:123)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:95)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:76)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:55)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:236)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:61)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:228)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:215)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:77)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:58)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:32)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:113)
at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.access$000(DefaultBuildExecuter.java:23)
at org.gradle.execution.DefaultBuildExecuter$1.proceed(DefaultBuildExecuter.java:43)
at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:37)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:30)
at org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:256)
at org.gradle.initialization.DefaultGradleLauncher$RunTasksAction.execute(DefaultGradleLauncher.java:253)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:175)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:119)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:102)
at org.gradle.launcher.exec.GradleBuildController.run(GradleBuildController.java:71)
at org.gradle.tooling.internal.provider.runner.BuildModelActionRunner.run(BuildModelActionRunner.java:50)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.tooling.internal.provider.runner.RunAsBuildOperationBuildActionRunner$1.execute(RunAsBuildOperationBuildActionRunner.java:43)
at org.gradle.tooling.internal.provider.runner.RunAsBuildOperationBuildActionRunner$1.execute(RunAsBuildOperationBuildActionRunner.java:40)
at org.gradle.internal.Transformers$4.transform(Transformers.java:169)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:106)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:56)
at org.gradle.tooling.internal.provider.runner.RunAsBuildOperationBuildActionRunner.run(RunAsBuildOperationBuildActionRunner.java:40)
at org.gradle.tooling.internal.provider.runner.SubscribableBuildActionRunner.run(SubscribableBuildActionRunner.java:75)
at org.gradle.launcher.exec.ChainingBuildActionRunner.run(ChainingBuildActionRunner.java:35)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:41)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:75)
at org.gradle.tooling.internal.provider.ContinuousBuildActionExecuter.execute(ContinuousBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:49)
at org.gradle.tooling.internal.provider.ServicesSetupBuildActionExecuter.execute(ServicesSetupBuildActionExecuter.java:31)
at org.gradle.launcher.daemon.server.exec.ExecuteBuild.doBuild(ExecuteBuild.java:67)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.WatchForDisconnection.execute(WatchForDisconnection.java:47)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ResetDeprecationLogger.execute(ResetDeprecationLogger.java:26)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.RequestStopIfSingleUsedDaemon.execute(RequestStopIfSingleUsedDaemon.java:34)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:74)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput$2.call(ForwardClientInput.java:72)
at org.gradle.util.Swapper.swap(Swapper.java:38)
at org.gradle.launcher.daemon.server.exec.ForwardClientInput.execute(ForwardClientInput.java:72)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogAndCheckHealth.execute(LogAndCheckHealth.java:55)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.LogToClient.doBuild(LogToClient.java:60)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.EstablishBuildEnvironment.doBuild(EstablishBuildEnvironment.java:72)
at org.gradle.launcher.daemon.server.exec.BuildCommandOnly.execute(BuildCommandOnly.java:36)
at org.gradle.launcher.daemon.server.api.DaemonCommandExecution.proceed(DaemonCommandExecution.java:120)
at org.gradle.launcher.daemon.server.exec.StartBuildOrRespondWithBusy$1.run(StartBuildOrRespondWithBusy.java:50)
at org.gradle.launcher.daemon.server.DaemonStateCoordinator$1.run(DaemonStateCoordinator.java:297)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

1 error`

See #708.

authors: cushon m-titov

repo: google/error-prone