Re: [go-nuts] why math.Pow gives different results depending on exp type

[Dominik Honnef]

Also, Staticcheck catches this:

$ curl -Os https://go.dev/play/p/oIKGb_uyLb3.go
$ staticcheck oIKGb_uyLb3.go 
oIKGb_uyLb3.go:9:38: the integer division '1 / 13' results in zero (SA4025)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87cyqkm409.fsf%40honnef.co.

Re: [go-nuts] google code style is the same as gofmt in go codes?

[Dominik Honnef]

gofmt's output does not depend on the displayed width of a tab.
Indentation uses tabs, alignment within a line uses spaces, and there is
no alignment directly following indentation.

Note that go/printer allows for configurations other than the one used
by go/format / gofmt. It allows indenting with spaces and aligning with
tabs; the tab width matters for at least one of those non-standard
formats.

As far as I can tell, the tab width specified in go/format is
irrelevant, and setting it to other values doesn't break any of the
tests.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/87illqzwym.fsf%40honnef.co.

Re: [go-nuts] Go += Package Versioning

[Dominik Honnef]

Hi,

I'd like your input on two concern I have, one as a tool developer and
one with regard to reproducible builds.

With go and go get, it is expected that code will not compile until
all dependencies have been explicitly downloaded. Hence, it is
acceptable for tools such as staticcheck to also fail if dependencies
are not present. Vgo seems to change this, by promising the user that
dependencies will be automatically downloaded. Running `vgo build` at
any point will "just work". Tools, however, do not have this luxury,
for multiple reasons:

- Multiple tools may run in parallel, either via helpers such as
gometalinter, or simply because editors like Emacs launch multiple
tools at once, for example when saving a file. This is likely prone to
race conditions. File locking may be an option, but file locking is
known to cause erratic problems on networked file systems, or be
outright unsupported.
- Fetching the dependencies, e.g. via 'vgo build', has the side-effect
of modifying the go.mod file. This is probably unacceptable for tools
that are run automatically, without the user's express wish to add new
dependencies to the go.mod file.
- If we do find a solution to these two problems, we'd probably still
want a 'vgo get' (with no arguments), to just fetch the dependencies,
without also incurring a costly build.

In my opinion, tools should behave as closely as possible to (v)go
build, so that users can operate on a single set of expectations.

My second concern is regarding the promise of getting rid of the
vendor directory. Reproducible builds not only depend on versioning,
but also on ensuring that code doesn't go away, be it due to server
downtime or more permanent reasons. Vendoring makes this rather easy:
add your dependencies to vendor and commit them, and your project is
now self-contained. Vgo seems to discourage this practice. Can you
suggest an alternative that is as straightforward as vendoring? All
other solutions - which amount to various forms of proxies and mirrors
- are significantly more laboursome.

I have noticed that currently, vgo downloads dependencies into GOPATH.
Are there any plans to instead store them with the module itself,
possibly in a way that facilitates committing them to version control?

On Tue, Feb 20, 2018 at 6:20 PM, Russ Cox  wrote:
> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
> --
> 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.

[go-nuts] Looking for a maintainer for honnef.co/go/augeas

[Dominik Honnef]

Hi,

I'm looking for a maintainer for honnef.co/go/augeas, a set of
cgo bindings for Augeas[1]. It's a relatively small library, but
it hasn't been keeping up with Augeas development for the past
couple of months and might be missing newer APIs.

The maintainer would be responsible for all the usual tasks:
Merging PRs, responding to issues, fixing bugs. None of which
there are terribly many of.

Ideally, the maintainer would use Augeas regularly, but that's
really not a requirement at this point.

Please respond to this thread if you'd like to become a
maintainer. Alternatively, feel free to email me in private.

Thanks!

[1] http://augeas.net/

-- 
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.