Re: [go-nuts] call of non-function C.testc
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 However, it does not look like a 32-bit SPARC. Please see below: -bash-4.3$ isainfo -v 64-bit sparcv9 applications crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc 32-bit sparc applications crc32c cbcond pause mont mpmul sha512 sha256 sha1 md5 camellia des aes ima hpc vis3 fmaf asi_blk_init vis2 vis popc v8plus div32 mul32 How would I compile a 64-bit executable? Maybe that would work (exporting CFLAGS=-m64 does not seem to work) Regards, Aman On Monday, September 24, 2018 at 8:31:02 PM UTC-7, Ian Lance Taylor wrote: > > 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 command-line-arguments -gccgo -- -I $WORK/b001/ > -g > > -O2 ./sol10.go > > we see an error: > > not-type:1:33: error: '__cgo_undefined__2' undeclared (first use in this > > function); did you mean '__cgo_f_1_2'? > > Could that be an issue? > > That is normal enough. What cgo does is create a little file, compile > it, and then examine which lines get errors. And error on this line > means that the corresponding symbol is not a type. > > > > This looks awfully similar to https://github.com/golang/go/issues/18959. > > > Hmmm, that could indeed be the problem if this is 32-bit SPARC. > > > > I also created a bug: https://github.com/golang/go/issues/27838 with > all the > > details. > > Thanks. > > 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] call of non-function C.testc
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 command-line-arguments -gccgo -- -I $WORK/b001/ -g > -O2 ./sol10.go > we see an error: > not-type:1:33: error: '__cgo_undefined__2' undeclared (first use in this > function); did you mean '__cgo_f_1_2'? > Could that be an issue? That is normal enough. What cgo does is create a little file, compile it, and then examine which lines get errors. And error on this line means that the corresponding symbol is not a type. > This looks awfully similar to https://github.com/golang/go/issues/18959. Hmmm, that could indeed be the problem if this is 32-bit SPARC. > I also created a bug: https://github.com/golang/go/issues/27838 with all the > details. Thanks. 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] The If Statement: Switches are better except for a single condition (change my mind)
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 function. Goto based on a prior statement setting an error would be far more useful, which gets back to my conditional return idea (and then maybe this could be a pattern applied to these scope jumping functions in general, that they can be aborted by a false boolean. Goto is already bound within function scope anyway, so making it more useful couldn't do any real harm, and conditional branching would be the one. It's kinda ironic to me that such a simple idea is so infrequent in high level languages yet everywhere from the assembler macro preprocessor on down. Break, continue, goto, return, all of them would become amazing with conditional execution. For me, the novel if and for syntax was the biggest stand-out thing I noticed about Go, at the beginning. I had already got familiar with closures , and it took some time to absorb exactly what interfaces are about. They are amazing but the various cool features of if's pre-condition statement and the condition-only for (removing the need for the semicolons especially), these are a break outside of the very tired conventions of for if while wend foreach, etc etc, and let you structure the logic flow more intuitively and visually. Switches look nice and read well, but the keyword and block boundary raise the cost of casual use. On Tuesday, 25 September 2018 04:15:02 UTC+2, Robert Engels wrote: > > 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 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 judgement is worthwhile > > as to whether this is true for any particular situation. > > > >> On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: > >> 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... > > > > -- > > 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...@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] The If Statement: Switches are better except for a single condition (change my mind)
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 fmt.Errorf enough work? maybe there are three (for some value of three) places where this happens but a sparsely distributed enough that it makes sense to do the work at the site. The issue is that a simple rule does not take into account the situation's context. On Mon, 2018-09-24 at 21:14 -0500, Robert Engels wrote: > 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 -- 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] call of non-function C.testc
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/ -g -O2 ./sol10.go we see an error: not-type:1:33: error: '__cgo_undefined__2' undeclared (first use in this function); did you mean '__cgo_f_1_2'? Could that be an issue? This looks awfully similar to https://github.com/golang/go/issues/18959. I also created a bug: https://github.com/golang/go/issues/27838 with all the details. Thanks, Aman On Tuesday, September 18, 2018 at 8:40:12 PM UTC-7, Ian Lance Taylor wrote: > On Tue, Sep 18, 2018 at 6:30 PM, > > wrote: > > > > Well, that is bad news. I am not sure what to do next either. I am > setting > > up another Solaris 10 machine from scratch and then re-run this to see > if > > this can be replicated. Will get back to you if I am able to replicate. > > Should I file a big for this? > > Sure. Thanks. But since it works on Solaris 11 it doesn't seem high > priority. > > Ian > > > > On Tuesday, September 18, 2018 at 7:45:06 AM UTC-7, Ian Lance Taylor > wrote: > >> > >> Thanks for sending this. Unfortunately, I have no idea what is going > >> wrong. Everything that you sent looks as expected. At this point I > >> don't have any suggestions. > >> > >> Ian > >> > >> On Fri, Sep 14, 2018 at 6:42 PM, wrote: > >> > Hi Ian, > >> >I did you told, but I could not find --debug=all option for > readelf. > >> > However, there is --debug --all option with readelf. I am attaching > the > >> > output below: > >> > > >> > -bash-3.2$ /opt/csw/bin/greadelf --debug --all /b001/_cgo_.o > >> > ELF Header: > >> > Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 > >> > Class: ELF32 > >> > Data: 2's complement, big endian > >> > Version: 1 (current) > >> > OS/ABI:UNIX - System V > >> > ABI Version: 0 > >> > Type: REL (Relocatable file) > >> > Machine: Sparc > >> > Version: 0x1 > >> > Entry point address: 0x0 > >> > Start of program headers: 0 (bytes into file) > >> > Start of section headers: 2000 (bytes into file) > >> > Flags: 0x0 > >> > Size of this header: 52 (bytes) > >> > Size of program headers: 0 (bytes) > >> > Number of program headers: 0 > >> > Size of section headers: 40 (bytes) > >> > Number of section headers: 20 > >> > Section header string table index: 17 > >> > > >> > Section Headers: > >> > [Nr] Name TypeAddr OffSize ES > Flg > >> > Lk > >> > Inf Al > >> > [ 0] NULL 00 00 00 > >> > 0 > >> > 0 0 > >> > [ 1] .text PROGBITS 34 14 00 > AX > >> > 0 > >> > 0 4 > >> > [ 2] .rela.textRELA 000c4c 24 0c > >> > 18 > >> > 1 4 > >> > [ 3] .data PROGBITS 48 20 00 > WA > >> > 0 > >> > 0 8 > >> > [ 4] .bss NOBITS 68 00 00 > WA > >> > 0 > >> > 0 1 > >> > [ 5] .rodata.str1.8PROGBITS 68 10 01 > AMS > >> > 0 > >> > 0 8 > >> > [ 6] .debug_frame PROGBITS 78 20 00 > >> > 0 > >> > 0 4 > >> > [ 7] .rela.debug_frame RELA 000c70 18 0c > >> > 18 > >> > 6 4 > >> > [ 8] .debug_info PROGBITS 98 000290 00 > >> > 0 > >> > 0 1 > >> > [ 9] .rela.debug_info RELA 000c88 000240 0c > >> > 18 > >> > 8 4 > >> > [10] .debug_abbrev PROGBITS 000328 00011d 00 > >> > 0 > >> > 0 1 > >> > [11] .debug_arangesPROGBITS 000445 20 00 > >> > 0 > >> > 0 1 > >> > [12] .rela.debug_arang RELA 000ec8 18 0c > >> > 18 > >> > 11 4 > >> > [13] .debug_line PROGBITS 000465 000128 00 > >> > 0 > >> > 0 1 > >> > [14] .rela.debug_line RELA 000ee0 0c 0c > >> > 18 > >> > 13 4 > >> > [15] .debug_strPROGBITS 00058d 00017c 01 > MS > >> > 0 > >> > 0 1 > >> > [16] .comment PROGBITS 000709 1b 01 > MS > >> > 0 > >> > 0 1 > >> > [17] .shstrtab STRTAB 000724 aa 00 > >> > 0 > >> > 0 1 > >> > [18] .symtab SYMTAB 000af0 000120 10 > >> > 19 > >> > 13 4 > >> > [19] .strtab STRTAB 000c10 39 00
Re: [go-nuts] The If Statement: Switches are better except for a single condition (change my mind)
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 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 judgement is worthwhile > as to whether this is true for any particular situation. > >> On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: >> 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... > > -- > 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] The If Statement: Switches are better except for a single condition (change my mind)
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 judgement is worthwhile as to whether this is true for any particular situation. On Mon, 2018-09-24 at 20:11 -0500, robert engels wrote: > 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... -- 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] ints, floats package with Inter and Floater, etc?
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 why this wouldn’t be useful to provide in standard packages?
>
> Idea: If there were standard packages that provide basic interfaces akin to
> fmt.Stringer, for ints and floats (and all other basic types), with
> bidirectional conversion functions, might that go a long way toward filling
> some of the generics gaps?
>
> e.g.: https://play.golang.org/p/v1S1IMigoy6
>
> // in package ints
>
> type Inter interface {
> Int() int64
> FromInt(val int64)
> }
>
> func Max(a, b Inter) int64 {
> if a.Int() > b.Int() {
> return a.Int()
> }
> return b.Int()
> }
>
> so you could write ints.Max(a,b) for anything supporting the Inter
> interface.. Obviously a Less method would be avail, and could be used for a
> fully generic sort on slices where you check if the slice element type
> supports the interface (including Floater and Stringer), and it falls back on
> a big reflect.Kind switch in the worst case. I just wrote this and it seems
> ugly but useful when you really don’t know what you’ve got, and having the
> interface allows you to use things like Time values etc, and is probably
> faster than fully reflect-based.
>
> A similar Floater interface could be defined, maybe in math, and an entire
> generic version of the math library could be implemented as wrappers using
> the Floater interface — obviously a bit of runtime cost using the interface
> methods but seems like it would save a lot of casting and for
> non-performance-critical cases would probably be worth the cleaner code.
>
> If this was all defined as a standard package, then basically every type with
> relevant int, float, etc semantics could be expected to have the relevant
> interface methods, just like virtually everything has a Stringer interface,
> and you could very easily deal with just about any relevant type by defining
> the relevant interface-based methods..
>
> So anyway, what is the fatal flaw with this idea that I’m not seeing?
Thanks. Similar ideas have been suggested several times. This
approach doesn't provide any clean mechanism for working with multiple
types, as expected by the graph example in the current design draft.
It also leads to a proliferation of names: everybody has to learn
another name for each kind of basic type. It's also not enough to
talk about int, float, etc.; many of the examples in the design draft
are for slices of various types, but in the language as it is today as
[]int is not the same as a []Inter.
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] The If Statement: Switches are better except for a single condition (change my mind)
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 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 {
> 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 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] The If Statement: Switches are better except for a single condition (change my mind)
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 not a language that trades clarity for brevity. -- 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] The If Statement: Switches are better except for a single condition (change my mind)
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 {
> 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 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] ints, floats package with Inter and Floater, etc?
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: If there were standard packages that provide basic interfaces akin to
fmt.Stringer, for ints and floats (and all other basic types), with
bidirectional conversion functions, might that go a long way toward filling
some of the generics gaps?
e.g.: https://play.golang.org/p/v1S1IMigoy6
// in package ints
type Inter interface {
Int() int64
FromInt(val int64)
}
func Max(a, b Inter) int64 {
if a.Int() > b.Int() {
return a.Int()
}
return b.Int()
}
so you could write ints.Max(a,b) for anything supporting the Inter interface..
Obviously a Less method would be avail, and could be used for a fully generic
sort on slices where you check if the slice element type supports the interface
(including Floater and Stringer), and it falls back on a big reflect.Kind
switch in the worst case. I just wrote this and it seems ugly but useful when
you really don’t know what you’ve got, and having the interface allows you to
use things like Time values etc, and is probably faster than fully
reflect-based.
A similar Floater interface could be defined, maybe in math, and an entire
generic version of the math library could be implemented as wrappers using the
Floater interface — obviously a bit of runtime cost using the interface methods
but seems like it would save a lot of casting and for non-performance-critical
cases would probably be worth the cleaner code.
If this was all defined as a standard package, then basically every type with
relevant int, float, etc semantics could be expected to have the relevant
interface methods, just like virtually everything has a Stringer interface, and
you could very easily deal with just about any relevant type by defining the
relevant interface-based methods..
So anyway, what is the fatal flaw with this idea that I’m not seeing?
- Randy
--
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: Go vet reporting errors in vendor
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 CONSTRAINT VERSION > REVISION LATEST PKGS USED > github.com/BurntSushi/tomlv0.3.0 v0.3.0 >b26d9c3 v0.3.0 1 > github.com/Masterminds/semver v1.3.1 v1.3.1 >517734c v1.3.1 1 > github.com/davecgh/go-spewv1.1.1 v1.1.1 >8991bc2 v1.1.1 1 > github.com/docker/distribution* >edc3ab22 > github.com/fsnotify/fsnotify v1.4.7 v1.4.7 >c282820 v1.4.7 1 > github.com/ghodss/yaml* >73d445a1 > github.com/gobwas/globv0.2.3 v0.2.3 >5ccd90e v0.2.3 8 > github.com/gogo/protobuf * >c0656ed2 > github.com/golang/glog* >44145f01 > github.com/golang/mock^1.1.1 v1.1.1 >c34cdb4 v1.1.1 1 > github.com/golang/protobufv1.2.0 v1.2.0 >aa810b6 v1.2.0 5 > github.com/golang/snappy branch masterbranch master > 2e65f85 2e65f85 1 > github.com/google/gofuzz * >44d81051 > github.com/gorilla/contextv1.1.1 v1.1.1 >08b5f42 v1.1.1 1 > github.com/gorilla/mux^1.6.2 v1.6.2 >e3702be v1.6.2 1 > github.com/hashicorp/errwrap * >7554cd91 > github.com/hashicorp/go-cleanhttp ^0.5.0 v0.5.0 >e8ab9da v0.5.0 1 > github.com/hashicorp/go-rootcerts branch masterbranch master > 6bb64b3 6bb64b3 1 > github.com/hashicorp/go-sockaddr branch masterbranch master > 6d291a9 6d291a9 1 > github.com/hashicorp/hcl v1.0.0 v1.0.0 >8cb6e5b v1.0.0 10 > github.com/hashicorp/vault^0.11.1 v0.11.1 > 8575f8f v0.11.1 4 > github.com/inconshreveable/mousetrap v1.0 v1.0 >76626ae v1.0 1 > github.com/json-iterator/go * >13f86431 > github.com/magiconair/properties v1.8.0 v1.8.0 >c235336 v1.8.0 1 > github.com/mitchellh/go-homedir ^1.0.0 v1.0.0 >ae18d6b v1.0.0 1 > github.com/mitchellh/mapstructure v1.0.0 v1.0.0 >fa473d1 v1.0.0 1 > github.com/opencontainers/go-digest * >a6d0ee41 > github.com/pelletier/go-toml v1.2.0 v1.2.0 >c01d127 v1.2.0 1 > github.com/pmezard/go-difflib v1.0.0 v1.0.0 >792786c v1.0.0 1 > github.com/ryanuber/go-glob branch masterbranch master > 256dc44 256dc44 1 > github.com/sethgrid/pester^1.0.0 1.0.0 > 03e26c9 1.0.01 > github.com/sirupsen/logrus^1.0.6 v1.0.6 >3e01752 v1.0.6 1 > github.com/spf13/aferov1.1.2 v1.1.2 >d40851c v1.1.2 2 > github.com/spf13/cast v1.2.0 v1.2.0 >8965335 v1.2.0 1 > github.com/spf13/cobra^0.0.3 v0.0.3 >ef82de7 v0.0.3 1 > github.com/spf13/jwalterweathermanv1.0.0 v1.0.0 >4a4406e v1.0.0 1 > github.com/spf13/pflagv1.0.2 v1.0.2 >9a97c10 v1.0.2 1 > github.com/spf13/viper^1.2.0 v1.2.0 >8fb6420 v1.2.0 1 > github.com/stretchr/testify ^1.2.2 v1.2.2 >f35b8ab v1.2.2 1 > golang.org/x/crypto branch masterbranch master > 0e37d00 0e37d00 1 > golang.org/x/net branch masterbranch master > 2f5d238 2f5d238 7 > golang.org/x/sys branch masterbranch master > d47a0f3 90868a7 2 > golang.org/x/text v0.3.0 v0.3.0 >f21a4df v0.3.0 14 > golang.org/x/time *
[go-nuts] Re: Go vet reporting errors in vendor
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 b26d9c3 v0.3.0 1 github.com/Masterminds/semver v1.3.1 v1.3.1 517734c v1.3.1 1 github.com/davecgh/go-spewv1.1.1 v1.1.1 8991bc2 v1.1.1 1 github.com/docker/distribution* edc3ab22 github.com/fsnotify/fsnotify v1.4.7 v1.4.7 c282820 v1.4.7 1 github.com/ghodss/yaml* 73d445a1 github.com/gobwas/globv0.2.3 v0.2.3 5ccd90e v0.2.3 8 github.com/gogo/protobuf * c0656ed2 github.com/golang/glog* 44145f01 github.com/golang/mock^1.1.1 v1.1.1 c34cdb4 v1.1.1 1 github.com/golang/protobufv1.2.0 v1.2.0 aa810b6 v1.2.0 5 github.com/golang/snappy branch masterbranch master 2e65f85 2e65f85 1 github.com/google/gofuzz * 44d81051 github.com/gorilla/contextv1.1.1 v1.1.1 08b5f42 v1.1.1 1 github.com/gorilla/mux^1.6.2 v1.6.2 e3702be v1.6.2 1 github.com/hashicorp/errwrap * 7554cd91 github.com/hashicorp/go-cleanhttp ^0.5.0 v0.5.0 e8ab9da v0.5.0 1 github.com/hashicorp/go-rootcerts branch masterbranch master 6bb64b3 6bb64b3 1 github.com/hashicorp/go-sockaddr branch masterbranch master 6d291a9 6d291a9 1 github.com/hashicorp/hcl v1.0.0 v1.0.0 8cb6e5b v1.0.0 10 github.com/hashicorp/vault^0.11.1 v0.11.1 8575f8f v0.11.1 4 github.com/inconshreveable/mousetrap v1.0 v1.0 76626ae v1.0 1 github.com/json-iterator/go * 13f86431 github.com/magiconair/properties v1.8.0 v1.8.0 c235336 v1.8.0 1 github.com/mitchellh/go-homedir ^1.0.0 v1.0.0 ae18d6b v1.0.0 1 github.com/mitchellh/mapstructure v1.0.0 v1.0.0 fa473d1 v1.0.0 1 github.com/opencontainers/go-digest * a6d0ee41 github.com/pelletier/go-toml v1.2.0 v1.2.0 c01d127 v1.2.0 1 github.com/pmezard/go-difflib v1.0.0 v1.0.0 792786c v1.0.0 1 github.com/ryanuber/go-glob branch masterbranch master 256dc44 256dc44 1 github.com/sethgrid/pester^1.0.0 1.0.0 03e26c9 1.0.01 github.com/sirupsen/logrus^1.0.6 v1.0.6 3e01752 v1.0.6 1 github.com/spf13/aferov1.1.2 v1.1.2 d40851c v1.1.2 2 github.com/spf13/cast v1.2.0 v1.2.0 8965335 v1.2.0 1 github.com/spf13/cobra^0.0.3 v0.0.3 ef82de7 v0.0.3 1 github.com/spf13/jwalterweathermanv1.0.0 v1.0.0 4a4406e v1.0.0 1 github.com/spf13/pflagv1.0.2 v1.0.2 9a97c10 v1.0.2 1 github.com/spf13/viper^1.2.0 v1.2.0 8fb6420 v1.2.0 1 github.com/stretchr/testify ^1.2.2 v1.2.2 f35b8ab v1.2.2 1 golang.org/x/crypto branch masterbranch master 0e37d00 0e37d00 1 golang.org/x/net branch masterbranch master 2f5d238 2f5d238 7 golang.org/x/sys branch masterbranch master d47a0f3 90868a7 2 golang.org/x/text v0.3.0 v0.3.0 f21a4df v0.3.0 14 golang.org/x/time * f51c1271 google.golang.org/genprotobranch masterbranch master c3f76f3 221a8d4 1 google.golang.org/grpcv1.7.2 v1.7.2 5ffe308 v1.7.2 18 gopkg.in/inf.v0 v0.9.0 v0.9.0 3887ee9
[go-nuts] Re: Go vet reporting errors in vendor
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 Monday, September 24, 2018 at 11:25:11 AM UTC-7, Josh Harshman wrote: > > 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.golang.org/genproto/googleapis/rpc/status > vendor/ > google.golang.org/genproto/googleapis/rpc/status/status.pb.go:114:28: > undefined: proto.InternalMessageInfo > # > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/kubernetes/pkg/apis/core/v1 > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1298:61: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".DeleteOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1307:57: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".DeleteOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1311:86: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".DeleteOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1320:82: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".DeleteOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2314:57: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".ListOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2329:53: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".ListOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2333:80: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".ListOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2348:76: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".ListOptions > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2964:55: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".ObjectMeta > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2985:51: > undefined: " > github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1 > ".ObjectMeta > vendor/ > k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2985:51: > too many errors > > I recently switched from govendor to dep and am wondering if that is > causing the issue. > > Any help would be greatly appreciated! > -- 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] Go vet reporting errors in vendor
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.golang.org/genproto/googleapis/rpc/status vendor/google.golang.org/genproto/googleapis/rpc/status/status.pb.go:114:28: undefined: proto.InternalMessageInfo # github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/kubernetes/pkg/apis/core/v1 vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1298:61: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".DeleteOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1307:57: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".DeleteOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1311:86: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".DeleteOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:1320:82: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".DeleteOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2314:57: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".ListOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2329:53: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".ListOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2333:80: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".ListOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2348:76: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".ListOptions vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2964:55: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".ObjectMeta vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2985:51: undefined: "github.REDACTED.com/REDACTED/platform-haas/vendor/k8s.io/api/core/v1".ObjectMeta vendor/k8s.io/kubernetes/pkg/apis/core/v1/zz_generated.conversion.go:2985:51: too many errors I recently switched from govendor to dep and am wondering if that is causing the issue. Any help would be greatly appreciated! -- 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] Getting Go module versions from Git Log
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 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] cannot take the address of method()
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
>> addressofstring := ()
>> }
>>
>> func method() string {
>> return "value"
>> }
>>
>> https://play.golang.org/p/UbJ7SK0m9w6
>
> You can't take the address of a function call. The Go specification
> has further explanation of what you can take the address of.
> https://golang.org/ref/spec#Address_operators
>
> The reason you can't take the address of a function call is that it's
> ambiguous as to what memory location you're getting the address of. By
> not having this as a feature there doesn't need to be a rule to
> disambiguate that.
But see https://golang.org/issue/9097 (and https://golang.org/issue/22647).
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] The If Statement: Switches are better except for a single condition (change my mind)
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 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] The If Statement: Switches are better except for a single condition (change my mind)
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 > > 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 not quite follow the whole post but expression switch > **is evaluated in an exact order**: > > [Switch Statements](https://golang.org/ref/spec#Switch_statements) > :: In an expression switch, the switch expression is evaluated and the > case > :: expressions, which need not be constants, are evaluated left-to-right > and > :: top-to-bottom; the first one that equals the switch expression triggers > :: execution of the statements of the associated case; the other cases are > :: skipped. If no case matches and there is a "default" case, its > statements > :: are executed. There can be at most one default case and it may appear > :: anywhere in the "switch" statement. A missing switch expression is > :: equivalent to the boolean value true. > > > -- > Wojciech S. Czarnecki > << ^oo^ >> OHIR-RIPE > -- 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: A simplified generics constraint system.
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
this:
contract Numeric(T) {
Real(T)
Complex(T)
}
How this would work is described in the gist.
Alan
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 important respects:
>
> 1. It doesn't deal adequately with numeric precision and/or signed-ness.
>
> 2. It's incomplete in that it doesn't deal with types based on string or
> bool. Nor does it deal with the inter-convertible types: string/[]bool or
> string/[]rune which would be useful in practice.
>
> Now a combination of my 'union' and 'except' assertions would address both
> of these criticisms. However, I have decided that these are too complicated
> and could lead to some difficult scenarios for the compiler or human reader
> to sort out.
>
> Although I still subscribe to the view that: "a simple to use and
> understand solution that covers 90% is better than a complex one to cover
> 100%", I think this proposal can (and should) do much better than that -
> close to full coverage of *realistic* scenarios - while retaining its
> essential simplicity.
>
> I have therefore decided to make the following changes to the proposal:
>
> 1. The 'union' assertion idea has been dropped completely.
>
> 2. Instead, the number of built-in contracts has been augmented by the
> following:
>
>* Boolean - any boolean type
>* String - any string type
>* Bytes - any string type or byte slice.
>* Runes - any string type or rune slice
>
> This brings the number of built-in contracts up to 10 which is a lot but
> worthwhile, IMO, because of the extra expressiveness it will bring.
>
> I continue to take the view that complex types are best segregated from
> the other numeric types for the reasons I originally gave in the proposal
> and also because to do otherwise would require, for completeness, the
> addition of 3 more built-in contracts (Numeric, NonInteger and Addable).
>
> 3. The 'except' constraint idea has been adopted but in a much restricted
> form: it will only be able to list built-in numeric types which are to be
> excluded from the contract.
>
> To be consistent with the built-in contracts, excluded types will be
> deemed to include defined types with the same underlying type.
>
> The name will be changed to 'omit' which I think expresses its intent more
> clearly.
>
> 'omit' will enable us to deal properly with numeric types and, in
> particular, it will now be possible to build both 'Unsigned' and 'Signed'
> contracts from the Integer contract and also to disallow smaller integer
> types (such as int8 and uint8) where necessary.
>
> So that's a summary of what's changed and the revised proposal is still
> available at the same link:
> https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab
>
> As I said earlier, I hope Ian can make the draft design work (possibly
> with some simplifications in the light of feedback) but, if he can't, then
> I believe this proposal - which addresses the problem of
> operators/conversions in a different way - would be a plausible alternative.
>
> I'll shut up now (where have I heard that before)!
>
> Alan
>
> On Friday, September 14, 2018 at 11:32:29 AM UTC+1, alanfo wrote:
>>
>> It's now more than a fortnight since the Go 2 Draft Generics Design was
>> published and, like many others, I have spent considerable time:
>>
>> 1. Steeped in discussions about the draft.
>>
>> 2. Reading feedback papers by others (Roger Peppe's are particularly
>> illuminating) most of whom share my opinion that 'contracts' are
>> unsatisfactory and should be replaced, amended or simplified in various
>> ways.
>>
>> 3. Attempting to devise a workable alternative to contracts (as envisaged
>> in the draft) myself.
>>
>> I was then brought back to reality by this post by Robert Engels in the
>> 'Generics - Why contracts?' thread:
>>
>> "As I’ve said elsewhere, a SIMPLE to use and understand solution that
>> covers 90% is better than a complex one to cover 100% IMO, and fits in well
>> with the rest of Go design. Go leaves out a lot - and it's a good choice."
>>
>> This convinced me that the draft design itself and many third party
>> proposals (including my own) were too ambitious and what we needed was
>> something much simpler that gave us 90% coverage and which everybody could
>> understand.
>>
>> So I've added a simplified proposal to the feedback page which I feel
>> meets this more limited aim. For anyone interested, here's the
[go-nuts] Re: A simplified generics constraint system.
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 important respects: > > 1. It doesn't deal adequately with numeric precision and/or signed-ness. > > 2. It's incomplete in that it doesn't deal with types based on string or > bool. Nor does it deal with the inter-convertible types: string/[]bool or > string/[]rune which would be useful in practice. > > Now a combination of my 'union' and 'except' assertions would address both > of these criticisms. However, I have decided that these are too complicated > and could lead to some difficult scenarios for the compiler or human reader > to sort out. > > Although I still subscribe to the view that: "a simple to use and > understand solution that covers 90% is better than a complex one to cover > 100%", I think this proposal can (and should) do much better than that - > close to full coverage of *realistic* scenarios - while retaining its > essential simplicity. > > I have therefore decided to make the following changes to the proposal: > > 1. The 'union' assertion idea has been dropped completely. > > 2. Instead, the number of built-in contracts has been augmented by the > following: > >* Boolean - any boolean type >* String - any string type >* Bytes - any string type or byte slice. >* Runes - any string type or rune slice > > This brings the number of built-in contracts up to 10 which is a lot but > worthwhile, IMO, because of the extra expressiveness it will bring. > > I continue to take the view that complex types are best segregated from > the other numeric types for the reasons I originally gave in the proposal > and also because to do otherwise would require, for completeness, the > addition of 3 more built-in contracts (Numeric, NonInteger and Addable). > > 3. The 'except' constraint idea has been adopted but in a much restricted > form: it will only be able to list built-in numeric types which are to be > excluded from the contract. > > To be consistent with the built-in contracts, excluded types will be > deemed to include defined types with the same underlying type. > > The name will be changed to 'omit' which I think expresses its intent more > clearly. > > 'omit' will enable us to deal properly with numeric types and, in > particular, it will now be possible to build both 'Unsigned' and 'Signed' > contracts from the Integer contract and also to disallow smaller integer > types (such as int8 and uint8) where necessary. > > So that's a summary of what's changed and the revised proposal is still > available at the same link: > https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab > > As I said earlier, I hope Ian can make the draft design work (possibly > with some simplifications in the light of feedback) but, if he can't, then > I believe this proposal - which addresses the problem of > operators/conversions in a different way - would be a plausible alternative. > > I'll shut up now (where have I heard that before)! > > Alan > > On Friday, September 14, 2018 at 11:32:29 AM UTC+1, alanfo wrote: >> >> It's now more than a fortnight since the Go 2 Draft Generics Design was >> published and, like many others, I have spent considerable time: >> >> 1. Steeped in discussions about the draft. >> >> 2. Reading feedback papers by others (Roger Peppe's are particularly >> illuminating) most of whom share my opinion that 'contracts' are >> unsatisfactory and should be replaced, amended or simplified in various >> ways. >> >> 3. Attempting to devise a workable alternative to contracts (as envisaged >> in the draft) myself. >> >> I was then brought back to reality by this post by Robert Engels in the >> 'Generics - Why contracts?' thread: >> >> "As I’ve said elsewhere, a SIMPLE to use and understand solution that >> covers 90% is better than a complex one to cover 100% IMO, and fits in well >> with the rest of Go design. Go leaves out a lot - and it's a good choice." >> >> This convinced me that the draft design itself and many third party >> proposals (including my own) were too ambitious and what we needed was >> something much simpler that gave us 90% coverage and which everybody could >> understand. >> >> So I've added a simplified proposal to the feedback page which I feel >> meets this more limited aim. For anyone interested, here's the link: >> >> https://gist.github.com/alanfo/fb2438f376dac0db3be5664702f39aab >> >> Although the new proposal is largely a simplified version of my 'full >> fat' proposal, the paper itself is much more comprehensive as I've included >> notes on why I think certain contracts should be built-in (but not others) >> and have also tried to address the problems that were raised in the draft >> design and overview
Re: [go-nuts] The If Statement: Switches are better except for a single condition (change my mind)
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 not quite follow the whole post but expression switch **is evaluated in an exact order**: [Switch Statements](https://golang.org/ref/spec#Switch_statements) :: In an expression switch, the switch expression is evaluated and the case :: expressions, which need not be constants, are evaluated left-to-right and :: top-to-bottom; the first one that equals the switch expression triggers :: execution of the statements of the associated case; the other cases are :: skipped. If no case matches and there is a "default" case, its statements :: are executed. There can be at most one default case and it may appear :: anywhere in the "switch" statement. A missing switch expression is :: equivalent to the boolean value true. -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- 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] The If Statement: Switches are better except for a single condition (change my mind)
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,
which evens out the gap between if and switch.
But for precedent or exclusive conditions, and more than one condition in
general, it's neater to use a switch:
if {
} else {
}
versus
switch {
case
default:
}
It takes the same number of lines and about the same number of characters
but the switch makes the relationship between conditions more obvious (no
fallthroughs, meaning each case is exclusive) and from there on, exclusive
cases save one line compared to a more wordy chain of if {} else if {}.
In libraries I am writing at the moment, there is also another issue to
deal with. Working with pointers means always being at risk of receiving an
unallocated variable. As this would be a fallthrough case, it does not
benefit from the use of a case, nor does it really do it detriment. But
what I have found is that instead I can export the function of allocating
on demand and perhaps registering the receiver was nil in a status/error,
and a case with 3 lines of statement collapses to one assignment that hides
the conditional in the function, drastically reducing the repetition. Even
when the nil condition requires a different response (such as an array
length query) it's not harmful to use this to avoid the nil panic.
These kinds of repeated test-and-calls are a reason why I have proposed
conditional returns and a third switch section header that implies
fallthrough instead of requiring this additionally. Conditional returns
function like an if statement with a return, and fallthrough keyword for a
case type would make this conditional embedded in the function for
triggering allocation mostly redundant since its case can be concisely
specified to fall through, and it's more obvious what is meant compared to
my hackish solution.
--
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: When using 'go mod vendor' why are there lots of files missing?
> 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 module's vendor directory to include all packages needed to build and test all the main module's packages. It does not include test code for vendored packages. An alternative is to "vendor" the modules themselves: https://github.com/myitcv/go-modules-by-example/blob/master/012_modvendor/README.md -- 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: When using 'go mod vendor' why are there lots of files missing?
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 behavior: >> >> usage: go mod vendor [-v] >>> >>> Vendor resets the main module's vendor directory to include all packages >>> needed to build and test all the main module's packages. >>> It does not include test code for vendored packages. >>> >>> The -v flag causes vendor to print the names of vendored >>> modules and packages to standard error. >>> >> > > This just bit me, because it isn't copying required cc source files from a > parent directory of the package, leading to the cgo library not being able > to build: > > library > cpp/ > source1.cpp > go/ > lib.go > inc.cpp > > For better or worse, inc.cpp has had '#include "../cpp/source1.cpp"' in > it, and it has been working under glide as the whole project gets vendored. > But now under "go mod vendor" it throws away the non-go files leading to > missing cpp files. Is this intended behaviour, expecting that the Go source > should have everything it needs as siblings or children in the directory > structure? > > -- 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: When using 'go mod vendor' why are there lots of files missing?
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 behavior: > > usage: go mod vendor [-v] >> >> Vendor resets the main module's vendor directory to include all packages >> needed to build and test all the main module's packages. >> It does not include test code for vendored packages. >> >> The -v flag causes vendor to print the names of vendored >> modules and packages to standard error. >> > This just bit me, because it isn't copying required cc source files from a parent directory of the package, leading to the cgo library not being able to build: library cpp/ source1.cpp go/ lib.go inc.cpp For better or worse, inc.cpp has had '#include "../cpp/source1.cpp"' in it, and it has been working under glide as the whole project gets vendored. But now under "go mod vendor" it throws away the non-go files leading to missing cpp files. Is this intended behaviour, expecting that the Go source should have everything it needs as siblings or children in the directory structure? -- 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: Help tracking down module dependencies
On Mon, Sep 24, 2018 at 4:31 PM wrote: > Hi Justin, > > I'm not sure where that gotest.tools is coming from in your particular > build, and not sure of the root cause of the issue with your http proxy. > > However, one thing you could try is a 'replace' directive to try to get > gotest.tools directly from github. I don't know if that will help your > particular situation, but you could try adding something like the following > to the end of your go.mod file: > >replace gotest.tools => github.com/gotestyourself/gotest.tools > v2.1.0+incompatible > This fixed my problem. Thanks! My proxy is perfectly happy with the github.com domain. I still don't know where that original dependency was coming from, and it would have been really cool if "go mod" could have told me some more verbose output, since it obviously knows. > > There is some chance that might work around the issue with your http > proxy. (And if that starts to complain instead about a failed replace, you > could also try adding an explicit 'require gotest.tools > v2.1.0+incompatible' or maybe even 'require gotest.tools v0.0.0' in your > go.mod file). > > --thepudds > > On Sunday, September 23, 2018 at 7:59:36 PM UTC-4, Justin Israel wrote: >> >> I'm converting one of my internal projects from glide to a module, after >> having done two other conversions. But I am hitting a problem that I can't >> yet solve. >> >> $ GO111MODULE=on go mod tidy -v >> >> Fetching https://gotest.tools?go-get=1 >> https fetch failed: Get https://gotest.tools?go-get=1: Forbidden >> go: gotest.tools@v2.1.0+incompatible: unrecognized import path >> "gotest.tools" (https fetch failed: Get https://gotest.tools?go-get=1: >> Forbidden) >> go: error loading module requirements >> >> My http proxy won't let me access this, and I can't find usage of it >> anywhere in my own codebase or in the immediate dependencies (or even my >> $GOPATH). The mod subcommand isn't being very specific about where this >> dependency is coming from (even with the graph command). Any pointers would >> be greatly appreciated. The dependency didn't show up in my glide.lock >> originally. >> >> My module requirements are: >> >> require ( >> github.com/boltdb/bolt v1.3.1 >> github.com/elazarl/go-bindata-assetfs v1.0.0 >> github.com/gorilla/context v1.1.1 >> github.com/gorilla/mux v1.3.0 >> github.com/pborman/uuid v1.2.0 >> golang.org/x/sys v0.0.0-20170615053224-fb4cac33e319 >> gopkg.in/yaml.v2 v2.2.0 >> ) >> >> >> Justin >> > -- > 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] Golang, how dare you handle my checks! (Critique of error proposal)
Hi Sameer, Glad to hear someone's reading my posts re Go 2 error handling! Debate on generics simmers in multiple threads, but discussion of error handling, which impacts many more gophers and lines of code, has been almost non-existent. Reading the feedback wiki, one might surmise that the draft design fell wide of the mark. That begs the question, Where lies the mark? In quest thereof, I've added a Requirements section to the wiki, with links to @ianlancetaylor's original criteria list, and my own comprehensive list of possible requirements for a Go 2 error idiom. https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#requirements I also opened a thread regarding requirements on golang-dev last week, but no discussion has yet ensued. Cheers! Liam On Fri, Sep 21, 2018, 3:37 PM Sameer Ajmani wrote: > That's quite an interesting wiki page, thanks for sharing. > > On Thu, Sep 13, 2018 at 2:46 PM Liam Breck > wrote: > >> The contents of the feedback wiki are interesting. The Go 2 error >> proposal hasn't seen much support, and there are lots of >> counter-proposals... >> >> https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback >> >> >> On Mon, Sep 10, 2018, 6:11 AM Liam wrote: >> >>> >>> "Golang, how dare you handle my checks!" >>> A Critique of the Go check/handle Error Proposal >>> >>> >>> https://medium.com/@mnmnotmail/golang-how-dare-you-handle-my-checks-d5485f991289 >>> >>> -- 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] Generic alternatives: new basic types?
Just an aside, Java had generic type inference since 8, and has local variable
type inference in Java 9.
Personally, I hate type inference. I find myself continually needing to refer
to the docs to know what something is, when type inference is not used this
doesn’t happen as the code is self documenting. I think type inference is lazy.
Puts the burden on the maintainer forever when it would of been a small effort
up front. For things like lambdas it makes a bit more sense but barely.
Sent from my iPhone
> On Sep 23, 2018, at 11:43 PM, Ian Denhardt wrote:
>
> Quoting robert engels (2018-09-23 22:50:54)
>
>> I'm often confounded when people discuss Java (at least in comparison
>> to Go) as being "heavy". If you read early interviews with Gosling it
>> is clear that his design was more about what to leave out, not what to
>> include (macros, pre-processor, unsigned arithmetic, etc.) He is a
>> brilliant language designer, probably top 10 CS engineers, and I think
>> he's worth listening to. I think as people look to "enhance/improve"
>> Go, his thoughts and processes might be of value.
>
> I feel like a lot of the complaints about java being "heavy" comes down
> to sheer verbosity, some of which is an artifact of the language itself
> (no type inference whatsoever), and some of which is the way APIs tend
> to be designed; you have lots of identifiers that are like six words
> long, everything feels very pedantic a lot of the time. I've found java
> to be painful to write without an IDE and autocompletion (like,
> *physically* painful -- my bad pinky starts acting up after a while).
>
> None of this is really about the complexity of the language per se. But
> much of the discussion in this thread is about what kind of code we'll
> see in the wild if we add operator overloading to Go. I think Java is a
> good illustration of what that can do to a language. We could delve into
> what actually went wrong there, but the point is we need to think things
> through.
>
> It seems like Gosling had the right attitude re: simplicity,
> but somewhere something fell apart.
>
> I wasn't really around for the days when folks thought Java was this
> great simple thing. I started my CS bachelors' in '06; by then Java
> already had generics, and they felt very bolted on. They didn't really
> work with some of most commonly used types in the language (int,
> bool...). Java had this mantra of "everything is an object", but it
> rang hollow in light of that. So many aspects of the language seemed
> slapped together even then, when I had no basis for comparison. The
> subtyping rules for generics are different than the ones for arrays,
> because somebody failed to think through the implications of the array
> subtyping rules. This program tries to put a string in an array of
> integers:
>
>class Main {
>public static void main(String[] args) {
>Integer[] myInts = new Integer[10];
>Object[] myObjs = myInts;
>myObjs[0] = "Hello, World!";
>}
>}
>
> It typechecks! and when you run it, you get:
>
>Exception in thread "main" java.lang.ArrayStoreException: java.lang.String
>at Main.main(Main.java:5)
>
> By the time generics got added, that hole in the type system had bit
> people enough times that they didn't make the same mistake again. But
> it's another dark corner of the language that was frustrating to have to
> explain to undergrads years later when I was a TA. Not long after, the
> department just started teaching them Python instead.
>
> There are two lessons here, one about type theory and one about design.
>
> The design lesson is that "lets keep things simple," while a great
> principle, isn't a substitute for thinking through the details, and
> maybe even doing the math.
>
> The good news is that as we look at adding generics to Go, we have a
> much easier problem than the designers of Java did. The interactions
> between subtyping and parametric polymorphism are notoriously subtle and
> complex, and it's not surprising that smart people made the
> aforementioned mistake. I think some of the perceived weight of Java's
> generics comes from these complex interactions.
>
> But while Java has pervasive subtyping everywhere, Go barely has
> subtyping at all, and I have a hunch that the bits that look like
> subtyping at first can be formalized in terms of constructs that play
> much more nicely with generics.
>
> We can do this right, and have generics in Go be simple and feel like
> they belong there. But the current contract-based design is a
> non-solution. It's clear to me that we should be using interfaces
> instead, and that need something like operator overloading to make this
> work.
>
> I have a sketch of a design for the system in my head; hopefully by the
> end of next week I'll have time to write it down and share it.
>
> --
> You received this message because you are subscribed to the Google Groups
>
