profile
viewpoint
Andrew Gerrand adg Google Inc. Sydney, Australia https://golang.org/

nf/sigourney 330

A modular audio synthesizer

adg/game 134

adg/github-gmail 67

Chrome extension to show GitHub issue status in Gmail

adg/dt 48

diff traversal tool

rsc/tmp 27

/tmp

rsc/quote 23

Pithy sayings.

campoy/httplog 17

Easy and flexible logging of HTTP requests

adg/sched 16

Goroutine scheduling latency profiling

adg/gostrip 15

Command gostrip builds a minimal Go repository

rsc/sampler 7

sampler

created tagadg/weirdmodules

tagfoo/v0.1.0

A demonstration of strangely nested modules

created time in 7 days

created tagadg/weirdmodules

tagv0.2.0

A demonstration of strangely nested modules

created time in 7 days

created tagadg/weirdmodules

tagv0.1.0

A demonstration of strangely nested modules

created time in 7 days

create barnchadg/weirdmodules

branch : master

created branch time in 7 days

created repositoryadg/weirdmodules

A demonstration of strangely nested modules

created time in 7 days

issue commentgolang/go

x/tools/godoc: make codewalks more accessible to third parties

The general trend seems to be toward splitting things out of godoc. I think the last option makes sense, and is at least a sensible starting point regardless of where it ends up.

Merovius

comment created time in 9 days

issue commentupspin/upspin

"error communicating with [GCP-hosted server]" for second user

It looks like the Google Cloud Storage bucket permissions are wrong. They need to be set such that the bucket is world-readable. @grosse had some related issues recently; was this the solution?

On Wed, 4 Dec 2019 at 09:16, Tom Lieber notifications@github.com wrote:

I just tried restarting my instance, to no avail.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/upspin/upspin/issues/630?email_source=notifications&email_token=ACAOFFMSGCT5ZDC3MDOUCB3QW3LCLA5CNFSM4JU7HY4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF3AFPI#issuecomment-561382077, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAOFFMP7SLW5UEBXQQLEHDQW3LCLANCNFSM4JU7HY4A .

alltom

comment created time in 2 months

issue commentupspin/upspin

remove "-u" from "go get" docs?

Yep I think so

On Sat, 23 Nov 2019 at 09:30, Eric Grosse notifications@github.com wrote:

Now that we've migrated to go.mod, is it true that we should remove the -u from docs?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/upspin/upspin/issues/626?email_source=notifications&email_token=ACAOFFJ4BB6BUNJDRA36MC3QVBMRZA5CNFSM4JQWXN72YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H3QFXRA, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACAOFFN2WVWNO5E5VACBUALQVBMRZANCNFSM4JQWXN7Q .

n2vi

comment created time in 3 months

issue openedupspin/upspin

upspin-ui and upspinserver-gcp distributed without working -version flag

As part of migrating to Go modules I had to break the -version flag for both of our upspin-ui and upspinserver-gcp distributions (see upspin/gcp@2f974d3aa265c7a4d85b5df69b26d8773d2f1146). This bug tracks the fix.

created time in 3 months

issue commentpackage-url/purl-spec

Propose 1.0 Milestone

What kind of changes are permitted before the 1.0 release?

stevespringett

comment created time in 4 months

issue commentdgraph-io/dgraph

Test suite fails with a fresh checkout

It makes sense that you should have a lot of end-to-end tests, but it should be possible to run your unit tests without spinning up a cluster (IMO, anyway). Maybe this could be a longer term goal for the project?

adg

comment created time in 4 months

issue commentdgraph-io/dgraph

Test scripts assume GOPATH layout

If you saw the same error before and after modules were added, then I don't think it's related to this issue.

adg

comment created time in 4 months

issue commentdgraph-io/dgraph

dgraph live RDF parser does not support \u escape sequences in facets

Interestingly, it appears to work if you supply such an RDF as a mutation in dgraph-ratel.

adg

comment created time in 4 months

issue openeddgraph-io/dgraph

dgraph live RDF parser does not support \u escape sequences in facets

Dgraph's RDF parser used in dgraph live does not appear to understand \uXXXX escape sequences inside facets.

The dgraph documentation says that it uses the RDF N-Quad spec, which specifies support for the \uXXXX escape sequences, but dgraph's implementation does not appear to respect it.

I tried adding these test cases to the chunker pacakage's TestLex, and the second one fails:

diff --git a/chunker/rdf_parser_test.go b/chunker/rdf_parser_test.go
index f2c45df5..7c733bbd 100644
--- a/chunker/rdf_parser_test.go
+++ b/chunker/rdf_parser_test.go
@@ -503,6 +503,28 @@ var testNQuads = []struct {
                },
                expectedErr: false,
        },
+       {
+               input: `<alice> <lives> "wonderland" (friend="hatter").`,
+               nq: api.NQuad{
+                       Subject:     "alice",
+                       Predicate:   "lives",
+                       ObjectId:    "",
+                       ObjectValue: &api.Value{Val: &api.Value_DefaultVal{DefaultVal: `wonderland`}},
+                       Facets:      []*api.Facet{{Key: "friend", Value: []byte("hatter"), Tokens: []string{"\001hatter"}}},
+               },
+               expectedErr: false,
+       },
+       {
+               input: `<alice> <lives> "wonderland" (friend="hatter \u0045") .`,
+               nq: api.NQuad{
+                       Subject:     "alice",
+                       Predicate:   "lives",
+                       ObjectId:    "",
+                       ObjectValue: &api.Value{Val: &api.Value_DefaultVal{DefaultVal: `wonderland`}},
+                       Facets:      []*api.Facet{{Key: "friend", Value: []byte("hatter E"), Tokens: []string{"\001hatter E"}}},
+               },
+               expectedErr: false,
+       },
        {
                input:       `<alice> <lives> "\u004 wonderland" .`,
                expectedErr: true, // should have 4 hex values after \u

The failure:

--- FAIL: TestLex (0.00s)
    rdf_parser_test.go:1008: 
        	Error Trace:	rdf_parser_test.go:1008
        	Error:      	Received unexpected error:
        	            	while lexing <alice> <lives> "wonderland" (friend="hatter \u0045"). at line 1 column 37: Not a valid escape char: 'u'
        	            	github.com/dgraph-io/dgraph/lex.(*Lexer).ValidateResult
        	            		/Users/adg/t/dgraph/dgraph/lex/lexer.go:200
        	            	github.com/dgraph-io/dgraph/chunker.ParseRDF
        	            		/Users/adg/t/dgraph/dgraph/chunker/rdf_parser.go:84
        	            	github.com/dgraph-io/dgraph/chunker.TestLex
        	            		/Users/adg/t/dgraph/dgraph/chunker/rdf_parser_test.go:1000
        	            	testing.tRunner
        	            		/Users/adg/go/src/testing/testing.go:909
        	            	runtime.goexit
        	            		/Users/adg/go/src/runtime/asm_amd64.s:1357
        	Test:       	TestLex
        	Messages:   	Got error for input: "<alice> <lives> \"wonderland\" (friend=\"hatter \\u0045\")."
FAIL

This manifests itself in dgraph live in that if you pass it an RDF of the form

<alice> <lives> "wonderland" (friend="hatter \u0045") .
``
it will fail with the above error.

created time in 4 months

issue commentdgraph-io/dgraph

Test suite fails with a fresh checkout

I see. Having prerequisites outside of the tests themselves is a bit of a Go anti-pattern. The usual approach with these kinds of tests is to skip such tests if the external dependencies aren't available.

In my specific case, I was trying to run the tests for the chunker package, which if I understand correctly shouldn't really require a dgraph cluster (we shouldn't need a running cluster just to test a parser, right?).

--

There's another related issue, in that if the dgraph cluster isn't available, then the test binary quits with a log.Fatal, meaning that the other tests that don't require the cluster won't even run (if they would run after the tests that require dgraph). The more user-friendly way of aborting such tests is to call t.Fatal, rather that log.Fatal, so that the other tests may continue to run. Should I file an issue about that?

adg

comment created time in 4 months

issue commentdgraph-io/dgraph

Test scripts assume GOPATH layout

@lolcoolkat https://github.com/dgraph-io/dgraph/commit/0e73a57baf1cccc342cde2e0087c4fe155f1e8fa

adg

comment created time in 4 months

issue commentdgraph-io/dgraph

Test script continues regardless of command failures

You'd need to put the set -e in test.sh itself.

The main thing is that if a command in the test script fails, for whatever reason, then the script should stop. Otherwise something could fail, but the script may continue and otherwise think it has succeeded.

adg

comment created time in 4 months

issue openeddgraph-io/dgraph

Test script continues regardless of command failures

If you run test.sh without a required tool present, the script continues despite failures.

For example

$ ./test.sh
INFO: Running only unit tests
INFO: Running tests using the default cluster
/dgraph/contrib/scripts/functions.sh: line 15: pushd: /src/github.com/dgraph-io/dgraph/dgraph: No such file or directory
Rebuilding dgraph ...
/dgraph/contrib/scripts/functions.sh: line 20: make: command not found
/dgraph/contrib/scripts/functions.sh: line 22: docker: command not found
/dgraph/contrib/scripts/functions.sh: line 23: docker-compose: command not found

I think that the shebang line should include the -e flag, or the script should have set -e early on, so that the script doesn't continue if a command fails.

created time in 4 months

issue openeddgraph-io/dgraph

Test scripts assume GOPATH layout

Now that the project is being made to support modules, there are still some old GOPATH-isms that remain. In test.sh and some of the included scripts, there are assumptions that the repo will be checked out into $GOPATH/src/github.com/dgraph-io/dgraph, when with modules it may be checked out anywhere.

created time in 4 months

issue openeddgraph-io/dgraph

Test suite fails with a fresh checkout

The dgraph unit test suite has many failures if you try to run it from a fresh checkout with no other setup. I wasn't able to find any information about the requirements/prerequisites for running the test suite, but in general Go unit tests should just work from a fresh checkout.

I ran into this trying to debug an issue with dgraph's live loader. This is a big roadblock for me and my team.

What version of Dgraph are you using?

master

What is the hardware spec (RAM, OS)?

macOS, MacBook Pro

Steps to reproduce the issue (command/config used to run Dgraph).

git clone https://github.com/dgraph-io/dgraph cd dgraph go test ./...

Expected behaviour and actual result.

Passing tests.

Actual results.

Many failing tests. See the full log for details.

created time in 4 months

pull request commentdgraph-io/dgraph

Adopt Go Modules

(And it appears deepsource concurs: https://deepsource.io/gh/dgraph-io/dgraph/run/b952d01d-80d8-4aa3-a01b-e350765e4b7f/#go)

mangalaman93

comment created time in 4 months

pull request commentdgraph-io/dgraph

Adopt Go Modules

This change appears to be bad.

The go.sum file contains at least one entry that differs to the actual hash of the content.

To reproduce:

$ git clone https://github.com/dgraph-io/dgraph
$ cd dgraph/chunker
$ go test
go: downloading go.etcd.io/etcd v0.0.0-20190228193606-a943ad0ee4c9
go: downloading github.com/dgraph-io/ristretto v0.0.0-20190903064322-eb48d2f7ca30
verifying github.com/dgraph-io/ristretto@v0.0.0-20190903064322-eb48d2f7ca30: checksum mismatch
	downloaded: h1:2ymRTEtPu60vzv+YTIHHlJ3713Bl3G/MPc2BOc/OkzM=
	go.sum:     h1:FkdGlqxPjfHKdVUzS5dOSMeOkGjEG7PnR1RLbcEqw88=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.
mangalaman93

comment created time in 4 months

issue commentgolang/go

proposal: Go 2: text/template: allow template and block outputs to be chained

To achieve that, you can define a function like 'eval' yourself. For example:

		"eval": func(name string, arg interface{}) (string, error) {
			var buf bytes.Buffer
			err := t.ExecuteTemplate(&buf, name, arg)
			return buf.String(), err
		},

The trick is to make that function enclose the template variable itself, for example:

package main

import (
	"bytes"
	"encoding/base64"
	"log"
	"os"
	"text/template"
)

const tmplText = `
{{ define "letter" }}
Dear {{.Name}},
{{if .Attended}}It was a pleasure to see you at the wedding.
{{else}}It is a shame you couldn't make it to the wedding.{{end}}
{{with .Gift}}Thank you for the lovely {{.}}.
{{end}}
Best wishes,
Josie
{{ end }}
{{(eval "letter" .) | base64 }}
`

func main() {
	t := template.New("")
	t.Funcs(template.FuncMap{
		"eval": func(name string, arg interface{}) (string, error) {
			var buf bytes.Buffer
			err := t.ExecuteTemplate(&buf, name, arg)
			return buf.String(), err
		},
		"base64": func(s string) string {
			return base64.StdEncoding.EncodeToString([]byte(s))
		},
	})
	_, err := t.Parse(tmplText)
	if err != nil {
		log.Fatal(err)
	}
	err = t.Execute(os.Stdout, map[string]interface{}{
		"Name":     "Joe",
		"Attended": true,
		"Gift":     "shoes",
	})
	if err != nil {
		log.Fatal(err)
	}
}
sylr

comment created time in 4 months

issue commentupspin/upspin

`upspinserver` spending months in some sort of a read loop

I think the root issue is that the upspin.io/dir/server/tree.Tree type has a String method that does a nontrivial amount of work to stringify the Tree. This involves taking a lock, and possibly printing more log messages that invoke the Stringer again, causing infinite recursion. The straightforward fix is to simplify the Tree's Stringer method to just return a string representation of the Tree's state without mutating it at all. That was a case of bad design in the first place.

filmil

comment created time in 5 months

issue commentupspin/upspin

`upspinserver` spending months in some sort of a read loop

Did it stop doing this after you restarted it? Or is it reproducible?

You might want to run the server with the environment variable GOTRACEBACK=2 set, and then you can send a SIGQUIT to the process to get a stack trace. It'd be helpful to know what the server think's it's doing. The bug is probably something simple.

filmil

comment created time in 5 months

issue commentgolang/go

proposal: Go 2: text/template: allow template and block outputs to be chained

The third argument to the template statement is not a variadic; it's a pipeline, which is just the text/template way of saying "expression". It's consistent with the rest of the grammar.

Any change we make here would need to be compatible with the existing uses of text/template, so changing the meaning of the grammar there is a non-starter.

sylr

comment created time in 5 months

issue commentgolang/go

proposal: Go 2: text/template: allow template and block outputs to be chained

I can see how the feature would be useful, but the proposed syntax doesn't make sense. The syntax for a {{template}} block is:

{{template "name" pipeline}}

In the given example

{{ template "letter" . | GzipString | Base64EncodeString }}

the part that says

 . | GzipString | Base64EncodeString

would be considered the pipeline part. There'd need to be some other way to treat the template invocation as the value, for another pipeline. It's not clear how one might do that.

sylr

comment created time in 5 months

more