I think it's worth raising an issue for this. Vendoring should copy the
whole repo.
On Monday, 24 September 2018 07:43:24 UTC+1, Justin Israel wrote:
>
>
>
> On Tuesday, September 18, 2018 at 8:58:01 AM UTC+12, Frits van Bommel
> wrote:
>>
>> According to the help text that's the intended behav
> I think it's worth raising an issue for this. Vendoring should copy the whole
> repo.
This has been raised before (https://github.com/golang/go/issues/26366
amongst others). Vendoring is not defined to copy the whole repo:
$ go help mod vendor
usage: go mod vendor [-v]
Vendor resets the main
I am quite a fan of switch statements, they can make a list of responses to
a change in state very readable and orderly. But you have to remember a few
things about them. They don't evaluate in any definite order, so any
conditions that need more than one response need to use a fallthrough,
wh
On Mon, 24 Sep 2018 01:37:56 -0700 (PDT)
Louki Sumirniy wrote:
> I am quite a fan of switch statements, they can make a list of responses to
> a change in state very readable and orderly.
> But you have to remember a few things about them.
> They don't evaluate in any definite order,
I did n
On Friday, September 21, 2018 at 5:51:37 PM UTC+1, alanfo wrote:
>
> Thanks to all those who have had the patience to read this proposal and
> made comments on, or criticisms of, it.
>
> Having carefully considered the points made, I have concluded that the
> current proposal falls short in two
For those who don't agree that complex numbers should be segregated from
the other numeric types, I'll briefly suspend my vow of silence to say that
I've found a way to do this which doesn't involve adding more built-in
contracts or fancy syntax to the contract body. In fact, it's as simple as
Ah, I wasn't quite clear on that. That does make them a lot even more
useful.
On Monday, 24 September 2018 11:12:38 UTC+2, ohir wrote:
>
> On Mon, 24 Sep 2018 01:37:56 -0700 (PDT)
> Louki Sumirniy > wrote:
>
> > I am quite a fan of switch statements, they can make a list of responses
> to
> >
You never used:
switch {
case err == io.EOF:
...
return
case err != nil:
...
return
default:
...
}
or similar (the default portion has a few, slightly different options,
depending on preceding code)???
Lucio.
>
>>
--
You received this message because you are subscribed to the Goo
On Sun, Sep 23, 2018 at 8:24 PM, Jesse McNelis wrote:
> On Mon, Sep 24, 2018 at 5:33 AM, Tamás Király wrote:
>> Hi,
>>
>> can anyone explain why the following does not work?
>> i want to have the return value's address not the method itself.
>>
>> package main
>>
>> func main() {
>> //first
>> ad
Hi all,
Here's a quick Git config for getting go module meta-versions from Git Log
output, hopefully its useful to someone else who was getting frustrated by
trying to make up v0.0.0 versions:
https://blog.samwhited.com/2018/09/go-module-versions-from-git-log/
—Sam
--
You received this messa
I'm running `go vet` as part of the CI process for my app, more
specifically I am running `go vet $(go list ./... | grep -v '/vendor/')`.
Problem is I am getting errors on vendored packages.
go vet $(go list ./... | grep -v 'vendor')
#
github.REDACTED.com/REDACTED/platform-haas/vendor/google.gol
Here I go starting to answer my own question :D
Solved the first issue by updating the vendored version of
github.com/golang/protobuf. I saw that my version didn't define the
InternalMessageInfo type and that upstream did.
My guess is that during solve, dep didn't pull the correct version.
On
Tried updating other packages and got into a vicious cycle of
incompatibilities.
Here is my dep status
PROJECT CONSTRAINT VERSION
REVISION LATEST PKGS USED
github.com/BurntSushi/tomlv0.3.0 v0.3.0
b26
Correction, the the first error on the output of go vet is solved.
On Monday, September 24, 2018 at 3:26:27 PM UTC-7, Josh Harshman wrote:
>
> Tried updating other packages and got into a vicious cycle of
> incompatibilities.
>
> Here is my dep status
> PROJECT CONST
This seems like such an obvious idea, but I was unable to find prior discussion
about it — it is probably at least implicit in various generics alternative
proposals etc, but anyway, seems like it might be worth at least saying why
this wouldn’t be useful to provide in standard packages?
Idea:
Using named return values and this construction you can drop all those
returns in each case block to outside the block. You only need to spend an
extra line if you have to break out of it by return or break.
On Monday, 24 September 2018 16:01:23 UTC+2, Lucio wrote:
>
> You never used:
>
> switch
On Tuesday, 25 September 2018 10:22:52 UTC+10, Louki Sumirniy wrote:
>
> Using named return values and this construction you can drop all those
> returns in each case block to outside the block. You only need to spend an
> extra line if you have to break out of it by return or break.
>
Go is n
You should always return from the place of return, or goto return_label, when a
result/error needs to be formatted.
See the Knuth paper I posted a while ago on using goto...
> On Sep 24, 2018, at 7:22 PM, Louki Sumirniy
> wrote:
>
> Using named return values and this construction you can drop
On Mon, Sep 24, 2018 at 4:32 PM, Randall O'Reilly wrote:
>
> This seems like such an obvious idea, but I was unable to find prior
> discussion about it — it is probably at least implicit in various generics
> alternative proposals etc, but anyway, seems like it might be worth at least
> saying
Rule: All rules are bad (including this one).
goto is useful when there is a need to do some elaborate clean up (or
other work) at the postamble of a function, but in many cases it
becomes clearer to have the work done at the location (say in the
switch in the example in this thread). Use of judge
Pretty sure that is what I said... duplicate the work in every case is silly,
thus the goto... if no work, no need for goto
> On Sep 24, 2018, at 9:10 PM, Dan Kortschak
> wrote:
>
> Rule: All rules are bad (including this one).
>
> goto is useful when there is a need to do some elaborate clea
Hi Ian,
I configured everything from scratch again and it seems that this is
reproducible. I also noticed that while running:
CGO_LDFLAGS='"-g" "-O2"' /usr/gnu/libexec/gcc/sparc-sun-solaris2.10/8.2.1/cgo
-debug-gcc -objdir $WORK/b001/ -importpath command-line-arguments -gccgo --
-I $WORK/b001
There are two extremes: lots of work, most likely use goto or factor
into a returning function (this is probably more commonly used in Go
unless there is locally scoped data that would make a call onerous); no
work - probably use a return at the site.
However, where does the boundary exists. Is fm
Goto isn't used often in Go because it has to be invoked on its own line
inside a conditional statement block, which often can perform the same
decision if you think it through, as well as moving shared elements into
functions that share the receiver or have common interfaces, outside of the
fu
On Mon, Sep 24, 2018 at 7:21 PM, wrote:
>
>I configured everything from scratch again and it seems that this is
> reproducible. I also noticed that while running:
> CGO_LDFLAGS='"-g" "-O2"'
> /usr/gnu/libexec/gcc/sparc-sun-solaris2.10/8.2.1/cgo -debug-gcc -objdir
> $WORK/b001/ -importpath com
Hello Ian,
Since you mention about 32-bit SPARC, I did a little testing. It seems
that gccgo is compiling 32-bit binary by default:
-bash-4.3$ go build abcd.go
-bash-4.3$ file abcd
abcd: ELF 32-bit MSB executable SPARC32PLUS Version 1, V8+
Required, dynamically linked, not stripped
26 matches
Mail list logo
