Re: [go-nuts] Does not match go tool version "go1.11.2"

On Mon, Nov 26, 2018 at 8:08 PM Freddy Martinez wrote: > > Hey Guys.. I'm really new with go (only 4 days) and I'm trying to install > graphql-go and I have this error > > > freddy@Freddys-MacBook-Pro:~/go$ go get github.com/graphql-go/graphql > > # internal/race > > compile: version "go1.11"

[go-nuts] contracts thought experiment: dimension checks

Just a silly idea: what if you make the dimensions (m,n) part of the type, not just T, somehow? -- 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

[go-nuts] Re: contracts thought experiment: dimension checks

On Mon, Nov 26, 2018 at 5:14 PM Dan Kortschak wrote: > > Background: > > As part of the Gonum dev team, I have an interest in using Go for > scientific computing. This stems from long experience with unsafe > computing environments often used in, particularly, bioinformatics > (perl, python and R

Re: [go-nuts] contracts thought experiment: dimension checks

On Mon, Nov 26, 2018 at 6:15 PM Dan Kortschak wrote: > > Background: > > As part of the Gonum dev team, I have an interest in using Go for > scientific computing. This stems from long experience with unsafe > computing environments often used in, particularly, bioinformatics > (perl, python and R

Re: [go-nuts] How to write unit test for init()?

On Tue, 27 Nov 2018, 11:08 Vast Peng > > when importing *component*, Golang will call *init() *automatically. > One way to do it is by moving the init into another function and call it from init. That way you can create test for the function. > -- You received this message because you are

[go-nuts] How to write unit test for init()?

The code below: package component import "os" type BaseicConfig struct{ } func init() { configDir := os.Getenv(constant.ProjectRootEnv) if configDir == "" { // run here. log.Panic(constant.InvalidEnvVariables) } configPath := filepath.Join(configDir, constant.ConfigName) if _, err :=

[go-nuts] Does not match go tool version "go1.11.2"

Hey Guys.. I'm really new with go (only 4 days) and I'm trying to install graphql-go and I have this error freddy@Freddys-MacBook-Pro:~/go$ go get github.com/graphql-go/graphql # internal/race compile: version "go1.11" does not match go tool version "go1.11.2" # unicode/utf8 compile:

Re: [go-nuts] The most performant deque of all time?

No problem, but just one last word on this… You have 748 lines of internal unit tests and only 295 lines of actual code.. This IMO does not lend itself to maintainable & flexible code. If your 295 lines needs 748 to verify its correctness something is wrong. You have an additional 400 lines

Re: [go-nuts] The most performant deque of all time?

Moved the non-unit tests to the "deque_test" package. The tests , package-wise, look as they should now. Thanks Robert for the suggestion. :-) On Mon, Nov 26, 2018 at 2:01 PM robert engels wrote: > It’s funny though, if you look at the container/ring tests, they

[go-nuts] contracts thought experiment: dimension checks

Background: As part of the Gonum dev team, I have an interest in using Go for scientific computing. This stems from long experience with unsafe computing environments often used in, particularly, bioinformatics (perl, python and R being standouts in the field, with packages that often use dubious

Re: [go-nuts] Important design missing from Errors overview

On Mon, Nov 26, 2018 at 1:31 PM wrote: > > While reading > https://go.googlesource.com/proposal/+/master/design/go2draft-error-values-overview.md#other-go-designs > I noticed that an important design is missing from the links below. I am > talking about Ben's

Re: [go-nuts] The most performant deque of all time?

It’s funny though, if you look at the container/ring tests, they test the internal structure, but there are no tests of the behavior, so if the data structure design is not correct, the tests will pass but the operations may not work as expected (especially after a refactor). A case of I know

Re: [go-nuts] The most performant deque of all time?

My “none” looks to have been a little strong… Clearly whoever wrote the container package believes in testing as the OP. A more in-depth review shows other packages with similar “private tests”, but typically they seem to be testing the public API only. Then there are packages like sync that

Re: [go-nuts] The most performant deque of all time?

container/ring (a arguably non-idiomatic stdlib package does indeed contain this kind of test). It also does not have in code asserts, which are something that I've found to be very rare in Go code. On Mon, 2018-11-26 at 12:09 -0600, robert engels wrote: > I am just offering, and many would

[go-nuts] Important design missing from Errors overview

Greetings, While reading https://go.googlesource.com/proposal/+/master/design/go2draft-error-values-overview.md#other-go-designs I noticed that an important design is missing from the links below. I am talking about Ben's https://middlemost.com/failure-is-your-domain/ which I think offers

Re: [go-nuts] The most performant deque of all time?

I like your thinking. Replacing UTs with asserts sounds pretty interesting to me. Let me give a good thought about it. There's clearly enormous potential, but there's also potentially many unforeseen implications. But we should continue this discussion offline or in a separate thread. I have duly

Re: [go-nuts] The most performant deque of all time?

If you re-read what you wrote you will see the problem - you weren’t setting a prev/next link correctly - the proper way test test these invariants IMO is to use asserts within the implementation itself - that way the implementation change change without breaking all of the tests. Otherwise

Re: [go-nuts] The most performant deque of all time?

It's funny because I'm not a big fan of unit testing for all the same reasons you mentioned. Impl7 , for instance, I didn't implement any unit tests as the implementation was very simple and integration

Re: [go-nuts] Re: GoAWK: an AWK interpreter written in Go

On Friday, November 23, 2018 at 1:58:37 PM UTC-7, Ben Hoyt wrote: > > So my main suggestion (for spakin/awk) would be able to wrap os.Stdout in > a bufio.NewWriter (and be sure to call Flush before Run finishes). If the > user wants to pass an unbuffered version, they still can, but at least the

[go-nuts] Any NULL CIPHER available in TLS package?

Hello All, Is there a TLS package in go that supports NULL CIPHER in TLS communication in go? I couldn't find any null cipher from the listed cipher suite IDs https://golang.org/pkg/crypto/tls/#pkg-constants for ex: SSL_RSA_WITH_NULL_MD5 I am working on a project that involves a go client to

Re: [go-nuts] At runtime, tell if a package path belongs to stdlib ?

On Mon, Nov 26, 2018 at 7:07 AM wrote: > > I m looking for a reliable way to determine if a package path string belongs > to the stdlib or not. > > It happens at runtime, the program can not access its sources. > > I m thinking to write package that stores those information into package >

Re: [go-nuts] Re: is it possible to speed up type assertion?

This logger https://github.com/ScottMansfield/nanolog is roughly 2x faster than ZAP and will work on all Go platforms. I want my logs to be collected and stored. I do not want to think where and when I can or can not log. 300ns and up (and not deterministic in my tests) blocking call is

Re: [go-nuts] Re: is it possible to speed up type assertion?

Why are you putting the ResetTimer() and StopTimer() calls in there ? Unnecessary AFAIK. Also, all this test is benchmarking is the time it takes to construct a Field struct. What is the point ? > On Nov 26, 2018, at 1:47 PM, lary...@gmail.com wrote: > > Talking about loggers and ZAP

Re: [go-nuts] Re: is it possible to speed up type assertion?

Talking about loggers and ZAP (interesting idea to accommodate API to the JSON) The following code gets 40ns/op type FieldType uint8 type Field struct { Key string Type FieldType Integer int64 Stringstring Interface interface{} } const ( // UnknownType

Re: [go-nuts] The most performant deque of all time?

I am just offering, and many would disagree, that unit tests that like are brittle and not worthwhile. I don’t see them in the Go stdlib for major packages, but I could be wrong. My thought on this is that if you are testing the nitty details of the implementation, you need to get that

Re: [go-nuts] The most performant deque of all time?

Hi Robert, the deque has unit, integration and API tests. The unit tests, I agree, are hard to follow as they have to check all internal properties to make sure the code is doing what it is supposed to do (keep a well formed ring linked list during all steps). Given their nature (unit tests), the

Re: [go-nuts] The most performant deque of all time?

Just an FYI, IMO your testing is incorrect. Your tests should be in a package dequeue_test so that they cannot access the internal details. This makes them brittle and hard to follow. For reference, look at the Go stdlib sync/map.go and sync/map_test.go. All of the tests are in sync_test for

[go-nuts] The most performant deque of all time?

Hello, I'm working on a logging system called CloudLogger and to cut to the chase, CloudLogger needs an unbounded in-memory queue. The idea is to use the queue as a sequential data store. As there's no telling beforehand how much data will need to be

Re: [go-nuts] net/http/httputil.ReverseProxy Expect: 100-continue broken?

Thanks, I pushed up the change you recommended -- reading the request body -- and indeed that fixed the test case. The weird TLS config thing I did was because the original problem we had (backend services, etc.) went away if we configured InsecureSkipVerify the usual straightforward way. The

Re: [go-nuts] Re: is it possible to speed up type assertion?

On Mon, 26 Nov 2018 at 16:44, wrote: > Do you mean this > // This is straight from the https://github.com/uber-go/zap plabook > func (b *Binlog) LogStructured(msg string, fields ...Field) error > > My first goal was to allow drop in replacement for the log package > I have to handle 50K

Re: [go-nuts] Re: is it possible to speed up type assertion?

Do you mean this // This is straight from the https://github.com/uber-go/zap plabook func (b *Binlog) LogStructured(msg string, fields ...Field) error My first goal was to allow drop in replacement for the log package I have to handle 50K queries/s on a mediocre machine. My time budget is

Re: [go-nuts] Re: is it possible to speed up type assertion?

On Mon, 26 Nov 2018 at 14:16, Arkady wrote: > ZAP is significantly slower than what I do. The binary log has an inherent > edge. AFAIK there is nothing about zap which precludes it from writing binary files. Unlike zap, your scheme will inherently incur more memory allocations, as it takes a

Re: [go-nuts] At runtime, tell if a package path belongs to stdlib ?

On Mon, Nov 26, 2018 at 4:55 PM wrote: > I was not referring to the file system path, i m referring to the import package path. FTR: The later is canonically called just "the import path". -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] At runtime, tell if a package path belongs to stdlib ?

thanks! It will be useful, indeed. Le lundi 26 novembre 2018 16:15:51 UTC+1, Shulhan a écrit : > > On Mon, 26 Nov 2018 07:07:34 -0800 (PST) > clement...@gmail.com wrote: > > > HI, > > > > I m looking for a reliable way to determine if a package path string > > belongs to the stdlib or not.

Re: [go-nuts] At runtime, tell if a package path belongs to stdlib ?

Hi, I was not referring to the file system path, i m referring to the import package path. Given the string bytes, reliably tells this is a package that belongs to the stdlib of version Y. I m using the reflect.Type.PkgPath value, to be more specific. Le lundi 26 novembre 2018 16:11:40

Re: [go-nuts] At runtime, tell if a package path belongs to stdlib ?

On Mon, 26 Nov 2018 07:07:34 -0800 (PST) clementauger...@gmail.com wrote: > HI, > > I m looking for a reliable way to determine if a package path string > belongs to the stdlib or not. > > It happens at runtime, the program can not access its sources. > > I m thinking to write package that

Re: [go-nuts] At runtime, tell if a package path belongs to stdlib ?

On Mon, Nov 26, 2018 at 4:07 PM wrote: > I m looking for a reliable way to determine if a package path string belongs to the stdlib or not. Check that the package path is bellow runtime.GOROOT(). -- -j -- You received this message because you are subscribed to the Google Groups

[go-nuts] At runtime, tell if a package path belongs to stdlib ?

HI, I m looking for a reliable way to determine if a package path string belongs to the stdlib or not. It happens at runtime, the program can not access its sources. I m thinking to write package that stores those information into package variables, into a map[go version][]packagesPaths. Do

[go-nuts] Re: is it possible to speed up type assertion?

Hello, Separate question, why are you passing an unsafe pointer to writer? You are (probably) forcing that int to escape to the heap. If you want to write an uint64, pass in a uint64. 1) I suspect that you are using pointer arithmetic inside writer, don't. The code will not be portable.

Re: [go-nuts] Re: is it possible to speed up type assertion?

On Sun, 25 Nov 2018 at 19:17, wrote: > These are great tips! Thank you! > This is the context for the code above > https://github.com/larytet/binlog/blob/master/binlog.go#L548 > I took a look at this code. It seems that you have a deep understanding of how the runtime works, but to me it really

Re: [go-nuts] gosnip: run small snippets of Go code from the command line

> > I've actually been using gomacro for this (testing a quick bit of syntax). > I have to import the std libs that I need (auto import would be nice if > it's not ambiguous), but it has nice output evaluation and state. > > https://github.com/cosmos72/gomacro > Ha, nice! You know, I think I

Re: [go-nuts] Re: is it possible to speed up type assertion?

Jan, I have just measured overall performance of my code - call to Log(string, args []interface{}). This code makes the difference type iface struct { tab *unsafe.Pointer data *unsafe.Pointer } func getInterfaceData(arg interface{}) unsafe.Pointer { return

Re: [go-nuts] Re: is it possible to speed up type assertion?

> The code below consumes ~40% of the total execution time. According to the profiler i := uint64(arg.(uint32)) is a major contributor > > // Cast the integer argument to uint64 and call a "writer" > // The "writer" knows how many bytes to add to the binary stream > // Type casts from interface{}

Re: [go-nuts] Re: is it possible to speed up type assertion?

P.S. shaves 20% from the total execution time. On Mon, Nov 26, 2018 at 10:22 AM wrote: > > The ugly hack below shaves 20% from the switch-case > type iface struct { > tab *unsafe.Pointer > data *unsafe.Pointer > } > > func getInterfaceData(arg interface{}) unsafe.Pointer { > return

[go-nuts] Re: is it possible to speed up type assertion?

The ugly hack below shaves 20% from the switch-case type iface struct { tab *unsafe.Pointer data *unsafe.Pointer } func getInterfaceData(arg interface{}) unsafe.Pointer { return unsafe.Pointer*iface)(unsafe.Pointer())).data)) } // Cast the integer argument to uint64 and call a