On Fri, May 26, 2017 at 1:32 PM, E Leong wrote:
>
> I'm trying to pass arguments to go test using
>
> go test -args -flag1 val1 -flag2 val2
>
> Documentation doesn't explain how one can extract flag1 and flag2 or their
> values from within the test.
> I am using os.Args to get to them, but that fe
I'm trying to pass arguments to go test using
go test -args -flag1 val1 -flag2 val2
Documentation doesn't explain how one can extract flag1 and flag2 or their
values from within the test.
I am using os.Args to get to them, but that feels like a hack.
The only documentation I see right now
in
On Fri, Nov 4, 2016 at 8:15 AM, Pritam Baral wrote:
> On Fri, Nov 4, 2016 at 8:28 PM, Ian Lance Taylor wrote:
>
>> `go build` takes a -o option that you can use to put the results where
>> you please.
>
> Yes, I use that. But that's only `-o`. In my original comment about gcc's
> `-o` I meant to
On Fri, Nov 4, 2016 at 8:28 PM, Ian Lance Taylor wrote:
> On Fri, Nov 4, 2016 at 7:37 AM, wrote:
> > Incremental build support in `go build` would be much appreciated.
> >
> > AIUI, the only way to have incremental builds using standard go tools are
> > through `go install`; but `go install` is
On Fri, Nov 4, 2016 at 7:37 AM, wrote:
> Incremental build support in `go build` would be much appreciated.
>
> AIUI, the only way to have incremental builds using standard go tools are
> through `go install`; but `go install` is not a compiler/linker/builder and
> it doesn't simply build a go pr
Incremental build support in `go build` would be much appreciated.
AIUI, the only way to have incremental builds using standard go tools are
through `go install`; but `go install` is not a compiler/linker/builder and
it doesn't simply build a go project.
Even if `go build` doesn't handle increm
That's a marvellous hack Aram!
It would still be nicer if there was an easier way though.
On 20 Oct 2016 20:09, "Aram Hăvărneanu" wrote:
On Wed, Oct 19, 2016 at 7:27 PM, Nate Finch wrote:
> Please give us an easy way to ensure all tests in a list of packages
compile
Do something like this:
Yes, just tried it, it works:
: emerald:aram; go test -toolexec toolexec_nolink -exec /usr/bin/true crypto...
? crypto [no test files]
ok crypto/aes 0.004s
ok crypto/cipher 0.012s
ok crypto/des 0.012s
ok crypto/dsa 0.011s
ok crypto/ecdsa 0.008s
ok crypto/elliptic 0.010s
ok crypto/h
On Wed, Oct 19, 2016 at 7:27 PM, Nate Finch wrote:
> Please give us an easy way to ensure all tests in a list of packages compile
Do something like this:
go test -toolexec wrapper -exec success pkgs...
Where wrapper is a binary that dispatches to the compiler, but a nop
when called with the
Even if there wasn't a -novendor flag, it would be nice if there was a
consistent way to ignore the /vendor/ directory. This approach was provided
by Andrew Gerrand's talk "Stupid Gopher Talks":
go test $(go list ./... | grep -v vendor)
However, the same doesn't work for all tools. The gofmt
There is a 2013 proposal from Russ Cox that includes a -watch flag in the
go tool.
https://docs.google.com/document/d/1xl_aRcCbksFRmCKtoyRQG9L7j6DIdMZtrkFAoi5EXaA/edit
"a possible extension would be to add -watch flag to “go test,” “go
> install,” and “go run,” which would repeat the command e
Please give us an easy way to ensure all tests in a list of packages
compile. right now I have to go test ./... -test.run=xxx ... and that
does all the linking and crap that I don't care about into N binaries,
which takes forever. I just want to know if I caught all the places that
need t
One tool I add to most of my projects is a Make target that opens
documentation for the current project in a web browser.
I wrote a short binary to do this
here: https://github.com/kevinburke/godocdoc
It would also be nice to be able to jump easily from a bug number,
e.g. 17391, to the relevan
go tool trace was nicely explained here
https://groups.google.com/forum/#!topic/Golang-Nuts/Ktvua7AGdkI
and had no proper documentation at the time. Would be good if it had a high
level overview like that
On Tuesday, 18 October 2016 19:54:49 UTC+1, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
Hi Jaana,
Thank you for this initiative.
I think currently one of the points that I think that is missing is easy to
access documentation online.
My use-case is usually around the web and making things easier to access
from there. Maybe I've got used to the command line for common tasks but
On Tuesday, 18 October 2016 14:02:08 UTC-5, Zellyn wrote:
>
> I run go tests with something like this:
>
> while true; do go test ./foo/bar; fswatch -1 -r . > /dev/null; sleep 0.3;
> done
>
>
> It would be nice if go test could do that itself. (The 0.3 second sleep is
> to let the file-write that
1. A "no vendor" switch (for build, test, fmt, vet, etc) would be nice.
2. Multi-package coverage would be nice. We end up copying this stanza
throughout our makefiles:
PACKAGES = $$(go list ./... | grep -v /vendor/)
test:
echo 'mode: atomic' > build/coverage.out
for pkg in $(PACKAGES) ; d
I run go tests with something like this:
while true; do go test ./foo/bar; fswatch -1 -r . > /dev/null; sleep 0.3;
done
It would be nice if go test could do that itself. (The 0.3 second sleep is
to let the file-write that triggered the test complete.)
Zellyn
On Tuesday, October 18, 2016 at
18 matches
Mail list logo
