Re: [go-nuts] Re: Tooling experience feedback

[Ian Lance Taylor]

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 feels like a hack.
>
> The only documentation I see right now in
> https://golang.org/cmd/go/#hdr-Description_of_testing_flags
>
> go test -v -args -x -v
>
>
> ... the -x and the second -v are passed through to the test binary unchanged
> and with no effect on the go command itself.

If you want your test program to have flags, use the flag package
(https://golang.org/pkg/flags) to define the flags you want.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[E Leong]

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 https://golang.org/cmd/go/#hdr-Description_of_testing_flags

go test -v -args -x -v


... the -x and the second -v are passed through to the test binary 
unchanged and with no effect on the go command itself. 

On Tuesday, October 18, 2016 at 11:54:49 AM UTC-7, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Tooling experience feedback

[Pritam Baral]

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 not a compiler/linker/builder
> and
> > it doesn't simply build a go project.
> >
> > Even if `go build` doesn't handle incremental builds, if I can use
> whatever
> > the equivalent of `gcc -c example.c -o example.o` and `gcc -o binary
> > example.o example2.o ...` are, I'd be happy, since then I could
> integrate it
> > with make. I'm guessing this has been asked before, since it sounds like
> a
> > wish I expect many people would have had, but I couldn't find any
> > discussions related to this.
>
> `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 point to the ability to link together compiled object
files, not to choose the output file name and location.


> I'm not sure what it means to have `go build` do an incremental build
>
It would mean to not recompile source files/packages that haven't changed.

without using `go install`.  Where would the intermediate files go,
>
A place of the user's choosing, with a safe default of "right beside the
corresponding source code". For comparison, whatever people do with gcc's
`-c`. As it stands now, there's no way for me to even instruct `go build`
to place the files specifically somewhere, or to not delete them after a
run.

and why would we want them in a place different than there `go
> install` puts them?
>
You may not want that. And that's fine. I'm not asking to change `go
install`'s default behaviour.
Some people might, like at my work, where we use separate workspaces and
projects with non github repos (and non go-gettable urls).

Like the difference between the conventional meanings of `make` and `make
install`. The former builds it locally, within the project; and the latter
does the actual installation to an intended location. Both support
incremental building (it's just make, after all). But `go install` is like
`make && make install`, and there's no way to split that into two
operations.

See also `go build -i`.
>
That makes `go build` fetch any dependencies it encounters, right? Does it
do anything relevant to incremental building?


> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Tooling experience feedback

[Ian Lance Taylor]

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 project.
>
> Even if `go build` doesn't handle incremental builds, if I can use whatever
> the equivalent of `gcc -c example.c -o example.o` and `gcc -o binary
> example.o example2.o ...` are, I'd be happy, since then I could integrate it
> with make. I'm guessing this has been asked before, since it sounds like a
> wish I expect many people would have had, but I couldn't find any
> discussions related to this.

`go build` takes a -o option that you can use to put the results where
you please.

I'm not sure what it means to have `go build` do an incremental build
without using `go install`.  Where would the intermediate files go,
and why would we want them in a place different than there `go
install` puts them?  See also `go build -i`.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[chhatoipritam]

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 incremental builds, if I can use whatever 
the equivalent of `gcc -c example.c -o example.o` and `gcc -o binary 
example.o example2.o ...` are, I'd be happy, since then I could integrate 
it with make. I'm guessing this has been asked before, since it sounds like 
a wish I expect many people would have had, but I couldn't find any 
discussions related to this.

On Wednesday, October 19, 2016 at 12:24:49 AM UTC+5:30, Jaana Burcu Dogan 
wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Tooling experience feedback

[roger peppe]

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:

go test -toolexec wrapper -exec success pkgs...

Where wrapper is a binary that dispatches to the compiler, but a nop
when called with the linker, and success is a binary that just exits
successfully.

--
Aram Hăvărneanu

--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Tooling experience feedback

[Aram Hăvărneanu]

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 linker, and success is a binary that just exits
successfully.

-- 
Aram Hăvărneanu

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[Nathan Youngman]

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 and golint tools 
report no such file or directory:

gofmt -s -l -w $(go list ./... | grep -v vendor) 
golint $(go list ./... | grep -v vendor)

This means our Makefile has a few different ways of getting the *.go files 
to check, and it took some time to figure out (multiply by every team / new 
project using Go).

Personally, I find it a bit confusing to get all these tools in the first 
place. I've heard that some of the x/tools have moved into core (gofmt) in 
1.6, but some haven't. There are a number of really useful third-party 
tools like gometalinter and gocode too. Right now it looks like each text 
editor / IDE needs to provide installation scripts to get all these tools.

Btw, the open issue for multiple package test coverage is here: 
https://github.com/golang/go/issues/6909

Thanks,
Nathan.

On Tuesday, 18 October 2016 13:27:30 UTC-6, Russ Egan wrote:
>
> 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) ; do \
>
> go test -v -covermode=count -coverprofile=build/coverage.tmp $$pkg 2>&1 | 
> tee -a build/test.out; \
>
> if [ -e build/coverage.tmp ] ; then tail -n +2 build/coverage.tmp >> 
> build/coverage.out; rm build/coverage.tmp; fi \
>
> done
>
> go tool cover -html=build/coverage.out -o build/coverage.html
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[Nathan Youngman]

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 each time a 
> prerequisite file was modified. For example, running “go test -watch” in a 
> terminal window would automatically show compile errors or test output each 
> time a source file was saved."


That might be nice to see, but it isn't a trivial project.

Nathan.



On Tuesday, 18 October 2016 13:02:08 UTC-6, 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 triggered the test complete.)
>
>
> Zellyn
>
> On Tuesday, October 18, 2016 at 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>>
>> Hello gophers,
>>
>> I am going to spend some time on improving the not-documented or 
>> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
>> test. The work will consist of reorganizing manuals, proposing new 
>> subcommands or flags to support commonly used multi-step things and so on.
>>
>> To give you some concrete examples:
>>
>> I have been in cases where users cannot find the build flags because they 
>> are hidden. E.g.
>>
>> $ go test -help
>> test [build/test flags] [packages] [build/test flags & test binary 
>> flags]
>> ...
>>
>> requires you to know about where the build flags are. Some tools are 
>> invisible for the newcomers.
>>
>> The other example is about test coverage. It is so tedious that I need an 
>> alias.
>>
>> func gocover() {
>> go test -v -coverprofile=coverage.out && go tool cover 
>> -html=coverage.out
>> } 
>>
>> I want to learn more about your experience, aliases, etc to propose 
>> improvements and work on the most commonly suggested items. I also am 
>> planning to go through this mailing list, stack overflow and other channels 
>> to see the common complaints.
>>
>> Feel free to reply to this thread or write to me privately.
>>
>> Thanks,
>> JBD
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[kburkeorg]

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 relevant description, e.g. 
github.com/golang/go/issues/17391.

On Tuesday, October 18, 2016 at 11:54:49 AM UTC-7, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[ondrej . kokes]

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,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[Florin Pățan]

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 
the things that are really hard to find are the special instructions to the 
go compiler and linker (gcflags and ldflags), like here for 
example: https://godoc.org/cmd/go And having all of this in a single page, 
while convenient can be overwhelming the first few times.

 Also the documentation, while from a godoc point of view logically lists 
the flags and tools / subtools, is rather well hidden for the things that 
you'd search as a newbie and while the Tour tries to teach you some aspects 
of the language, it doesn't show anything related to how to use the tools 
of the language (nor does it show how to install it correctly for example, 
many people still having problems with understanding how to correctly set 
their workspace with env vars and so on).

I think more usage examples should be shown in general, with concrete 
use-cases:
- this is how you test things
- this is how you test things without vendors (which is a major pita right 
now btw)
- this is how you also get the coverage
- this is how you compile and set a random string value at compile time
- etc.

I'll try and come up with more examples later on.

I also see the pattern in other apps where main command has some flags then 
the subcommand has other flags so I guess that's ok, probably introducing 
aliases would make it even more complex to use.


Kind regards,
Florin

On Tuesday, October 18, 2016 at 7:54:49 PM UTC+1, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[Egon]

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 triggered the test complete.)
>

I've built a tool for myself based on Watch by Russ Cox (he showed it in 
this video http://research.swtch.com/acme)

Located at: https://github.com/loov/watchrun


*$ go get github.com/loov/watchrun*
*$ watchrun go test ./foo/bar*

Keeping it as a separate tool is much more flexible and useful... e.g.

*$ watchrun go build myapp ;; myapp*

Which would build the application and then start it. Or... chain it with 
code generation...

*$ watchrun go generate . ;; go build . ;; myapp*

etc... of course depending on your needs you may want some other features 
or an alternative implementation.

Zellyn
>
> On Tuesday, October 18, 2016 at 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>>
>> Hello gophers,
>>
>> I am going to spend some time on improving the not-documented or 
>> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
>> test. The work will consist of reorganizing manuals, proposing new 
>> subcommands or flags to support commonly used multi-step things and so on.
>>
>> To give you some concrete examples:
>>
>> I have been in cases where users cannot find the build flags because they 
>> are hidden. E.g.
>>
>> $ go test -help
>> test [build/test flags] [packages] [build/test flags & test binary 
>> flags]
>> ...
>>
>> requires you to know about where the build flags are. Some tools are 
>> invisible for the newcomers.
>>
>> The other example is about test coverage. It is so tedious that I need an 
>> alias.
>>
>> func gocover() {
>> go test -v -coverprofile=coverage.out && go tool cover 
>> -html=coverage.out
>> } 
>>
>> I want to learn more about your experience, aliases, etc to propose 
>> improvements and work on the most commonly suggested items. I also am 
>> planning to go through this mailing list, stack overflow and other channels 
>> to see the common complaints.
>>
>> Feel free to reply to this thread or write to me privately.
>>
>> Thanks,
>> JBD
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[Russ Egan]

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) ; do \

go test -v -covermode=count -coverprofile=build/coverage.tmp $$pkg 2>&1 | 
tee -a build/test.out; \

if [ -e build/coverage.tmp ] ; then tail -n +2 build/coverage.tmp >> 
build/coverage.out; rm build/coverage.tmp; fi \

done

go tool cover -html=build/coverage.out -o build/coverage.html



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Tooling experience feedback

[Zellyn]

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 2:54:49 PM UTC-4, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
> I am going to spend some time on improving the not-documented or 
> hard-to-use parts of the Go tools. I will mainly focus on go build and go 
> test. The work will consist of reorganizing manuals, proposing new 
> subcommands or flags to support commonly used multi-step things and so on.
>
> To give you some concrete examples:
>
> I have been in cases where users cannot find the build flags because they 
> are hidden. E.g.
>
> $ go test -help
> test [build/test flags] [packages] [build/test flags & test binary 
> flags]
> ...
>
> requires you to know about where the build flags are. Some tools are 
> invisible for the newcomers.
>
> The other example is about test coverage. It is so tedious that I need an 
> alias.
>
> func gocover() {
> go test -v -coverprofile=coverage.out && go tool cover 
> -html=coverage.out
> } 
>
> I want to learn more about your experience, aliases, etc to propose 
> improvements and work on the most commonly suggested items. I also am 
> planning to go through this mailing list, stack overflow and other channels 
> to see the common complaints.
>
> Feel free to reply to this thread or write to me privately.
>
> Thanks,
> JBD
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.