Re: [go-nuts] "Craftsman's" Go Generics proposal

On Mon, 10 Sep 2018 15:31:41 -0500 robert engels wrote: > You would probably have simpler code just define an interface Value(), and > a ComplexValue() and two methods… ...and implement it on any single type I wanna sum? No, thanks. I am doing it already in Go1 :) > But even then, you need my pr

Re: [go-nuts] Gitlab CI loses its marbles attempting go get.

Todd Neal : > I took a look at https://gitlab.com/esr/reposurgeon/ > and put this together: > > FROM buildpack-deps:jessie > RUN apt-get update -qy && apt-get install -qy --no-install-recommends golang > git > RUN go version > > You’re running go1.3.3 whic

[go-nuts] Re: Cross-compile macOS binary with cgo DNS resolver enabled

I reported this issue as a potential go1.10 regression in https://github.com/golang/go/issues/27506. On Thursday, August 30, 2018 at 10:54:08 PM UTC-7, Julien Gricourt wrote: > > I'm trying to cross-compile a macOS binary in Docker with the cgo DNS > resolver enabled. My understanding is that th

[go-nuts] Sr. Developer needed in Atlanta GA

Hi Golang fanatics, I am a recruiter with Infinite, looking for a direct hire full time Golang Developer who is in or can relocate to the Atlanta, GA area. Salary is up to 130k. Aside from Golang, the preferred but not necessary skill-set would be Cloud experience and Blockchain. If this sounds

[go-nuts] Possible issue in contracts proposal

In the "Pointer vs. value methods in contracts" section, it says "that it will prevent writing a function body that requires a value method". But, the go spec states: That function may be called normally with an explicit receiver, so these five invocations are equivalent: t.Mv(7

Re: [go-nuts] Gitlab CI loses its marbles attempting go get.

> On Sep 10, 2018, at 8:17 PM, Eric S. Raymond wrote: > > Todd Neal : >> >>> On Sep 10, 2018, at 5:53 PM, 'Borman, Paul' via golang-nuts >>> wrote: >>> >>> Have you checked your Go version? >> >> This is likely the cause, I just tested with go 1.4.3 and get a similar >> error. I tested a

Re: [go-nuts] Gitlab CI loses its marbles attempting go get.

> On Sep 10, 2018, at 5:53 PM, 'Borman, Paul' via golang-nuts > wrote: > > Have you checked your Go version? This is likely the cause, I just tested with go 1.4.3 and get a similar error. I tested and both the golang:1.10.4-alpine3.8 and golang:1.11-alpine3.8 base images work fine. - Todd

[go-nuts] Computer Programmer - Information Technologist 4 (c, c++, Go)

*Job Description :* Computer Programmer - Information Technologist 4 (AESES) New Grant-Funded Project Full-Time 35.00 hours/week Monday to Friday 8:30-4:30 Salary Range: ($65,538.20 - $87,669.40 per annum). For more information, please contact: Andrea Toyne 753 McDermot Ave andrea.to...@umanit

Re: [go-nuts] Re: Generics as builtin typeclasses

The conversation here is deep, and I haven't followed all of it. I *think* y'all are discussing some different contract system than the actual draft proposal? If that's the case: You can't express field-accessors, which is an actual, inarguable reduction > in power that I'm perfectly fine wi

Re: [go-nuts] Gitlab CI loses its marbles attempting go get.

Todd Neal : > > > On Sep 10, 2018, at 5:53 PM, 'Borman, Paul' via golang-nuts > > wrote: > > > > Have you checked your Go version? > > This is likely the cause, I just tested with go 1.4.3 and get a similar > error. I tested and both the golang:1.10.4-alpine3.8 and > golang:1.11-alpine3.8 b

Re: [go-nuts] Re: Generics as builtin typeclasses

The unambiguous cases aren't ambiguous of course. It's the ambiguous cases I'm concerned about :) My post and this thread contain a bunch of those. They are mostly growing out of builtin functions and things like `range` statements and index-expressions. You can translate all of my "pseudo-interfa

Re: [go-nuts] Re: Generics as builtin typeclasses

On Monday, September 10, 2018 at 4:17:57 PM UTC-4, Axel Wagner wrote: > > On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam > wrote: > >> FWIW, I think Ian's criticism of not wanting a list of new identifiers to >>> express operator constraints is fair. It is a genuine roadblock to c) and >>>

Re: [go-nuts] Re: Generics as builtin typeclasses

Don't worry, I still got the point :) And already yielded that treating pseudo-interfaces as types won't work and that it requires some polish on phrasing :) On Tue, Sep 11, 2018 at 1:16 AM Jonathan Amsterdam wrote: > I'm wrong about `==` here, because it's defined for interface values. > `compa

Re: [go-nuts] Re: Generics as builtin typeclasses

I'm wrong about `==` here, because it's defined for interface values. `comparable` could be an interface. But it won't work for other operators like `<` or `+`. On Sunday, September 9, 2018 at 2:49:26 PM UTC-4, Jonathan Amsterdam wrote: > > FWIW, in my pseudo-interface description >>

[go-nuts] Re: Link: Getting specific about generics

Sorry, I'm wrong about `eq`. It could be an interface, because `==` is treated specially for interface types. But you couldn't have an interface for any other operator, like `<` or `+`. On Monday, September 10, 2018 at 9:55:04 AM UTC-4, Jonathan Amsterdam wrote: > > From the blog post: > > For e

Re: [go-nuts] Gitlab CI loses its marbles attempting go get.

Have you checked your Go version? On Sep 10, 2018, at 5:10 PM, Eric Raymond mailto:e...@thyrsus.com>> wrote: On Monday, September 10, 2018 at 5:56:23 PM UTC-4, Uli Kunitz wrote: Use GOPATH= go get -u golang.org/x/crypto/ssh/terminal The package g

[go-nuts] Re: Gitlab CI loses its marbles attempting go get.

On Monday, September 10, 2018 at 5:56:23 PM UTC-4, Uli Kunitz wrote: > > Use > > GOPATH= go get *-u* golang.org/x/crypto/ssh/terminal > > The package golang.org/x/sys/unix is probably old and requires updating. > I have no problems on my machine to go get -u > golang.org/x/crypto/ssh/termi

[go-nuts] Re: Gitlab CI loses its marbles attempting go get.

Use GOPATH= go get *-u* golang.org/x/crypto/ssh/terminal The package golang.org/x/sys/unix is probably old and requires updating. I have no problems on my machine to go get -u golang.org/x/crypto/ssh/terminal. So it is definitely not broken. -- You received this message because you are s

[go-nuts] Gitlab CI loses its marbles attempting go get.

Anyone seen behavior like this before? GOPATH=/builds/esr/reposurgeon go get golang.org/x/crypto/ssh/terminal # golang.org/x/sys/unix src/golang.org/x/sys/unix/env_unix.go:30: undefined: syscall.Unsetenv src/golang.org/x/sys/unix/ioctl.go:18: undefined: runtime.KeepAlive src/golang.org/x/sys/unix/

[go-nuts] Re: go 1.11 and XP

Go 1.11 doesn't support XP. We don't test on XP and won't fix bugs reported against XP systems any more. If it's working for you, great!, but if it breaks, you get to keep both pieces. Dave On Tuesday, 11 September 2018 05:05:23 UTC+10, wilk wrote: > > Hi, > > Go 1.11 is not more compatible wi

Re: [go-nuts] A thought on contracts

Personally, I'm not afraid of writing contracts manually. I suspect that in the vast majority of the cases the contract will be clear and pretty trivial. In fact, I think it could be a productive part of the design process to consider what your generic function minimally needs and write the co

Re: [go-nuts] "Craftsman's" Go Generics proposal

I would argue that is not generics code - the fact that you are type checking in the implementation is a problem, and replicating the logic for “each type”. You would probably have simpler code just define an interface Value(), and a ComplexValue() and two methods… But even then, you need my pro

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 8:57 PM Jonathan Amsterdam wrote: > FWIW, I think Ian's criticism of not wanting a list of new identifiers to >> express operator constraints is fair. It is a genuine roadblock to c) and >> if we're dead set of setting that as a baseline requirement, I agree that a >> decl

[go-nuts] "Craftsman's" Go Generics proposal

As empty criticism is bad, I felt compelled to give a consistent* counter-proposal. One that can make my "Craftsman wishes" code from previous post compile and run. Draft is available at https://github.com/ohir/gonerics Both criticism and applauds are welcome. -- Wojciech S. Czarnecki << ^oo^

[go-nuts] Generic types - functions and methods on instantions

Under the generics draft, would this be allowed? type Foo(type T) struct{} func f(x Foo(int)) {} I assume the answer is yes; I can't see any good reason to disallow it. What about this? func (x Foo(int)) Bar() {} If this is allowed, does this now mean that Foo(int) implements type Barrable

[go-nuts] go 1.11 and XP

Hi, Go 1.11 is not more compatible with Windows XP, but is it the compilator or the executable or both ? I just tried an app (build on linux) and doesn't see any failure... -- William -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubs

Re: [go-nuts] Re: Generics as builtin typeclasses

> > FWIW, I think Ian's criticism of not wanting a list of new identifiers to > express operator constraints is fair. It is a genuine roadblock to c) and > if we're dead set of setting that as a baseline requirement, I agree that a > declarative/interface-based approach won't work. > I don't

Re: [go-nuts] modules and package cyclic dips

> First, my overall point is that I have decided to use only acyclic > dependencies, as cyclic ones are too complicated for me. > I don't feel easily convincible otherwise; that comes from a combination of > using go modules where some cycles crept in > and a strong bias for a dead simple depende

Re: [go-nuts] [ANN] goey - Declarative, cross-platform GUIs

“wouldn’t be that hard" > On Sep 10, 2018, at 1:24 PM, robert engels wrote: > > I wonder about the design, and how it will work. Since it uses the native > components behind the scene, you will get great fidelity but the layout can > be very difficult to accomplish. > > This is why Java’s Swi

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

I wonder about the design, and how it will work. Since it uses the native components behind the scene, you will get great fidelity but the layout can be very difficult to accomplish. This is why Java’s Swing uses only a single native component (Canvas), and does all of the text/drawing/event ha

Re: [go-nuts] modules and package cyclic dips

Maybe if I say more it will help the communication/alleviate the disconnection: First, my overall point is that I have decided to use only acyclic dependencies, as cyclic ones are too complicated for me. I don't feel easily convincible otherwise; that comes from a combination of using go module

[go-nuts] What does it mean when runtime.MemStats.Alloc < resident memory usage of OS for go application

I have go application running. I print out runtime.MemStats in it. It shows: runtime.MemStats.Alloc = 71 MiB runtime.MemStats.TotalAlloc = 58118 MiB runtime.MemStats.Sys = 1595 MiB But when I use top command to get resident memory usage by my app, it shows that my app is using 400 MB for long tim

Re: [go-nuts] SQL Interceptor

Conrad Wood writes: > On Mon, 2018-09-10 at 09:44 +0200, Jan Mercl wrote: >> >> On Mon, Sep 10, 2018 at 8:16 AM Conrad Wood >> wrote: >> >> > Wdyt? Is that a patch that would be acceptable and generally >> useful? >> >> It could be tried and evaluated first as an external package. >> >> -- 

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 2:03 PM Jonathan Amsterdam wrote: > You and many others have tried to replace contracts with interfaces. > Almost, but not quite. I and others have tried to replace contracts with *something*. Preferably something declarative. ISMT interfaces fit the bill *pretty well*. I

Re: [go-nuts] Re: Generics as builtin typeclasses

Sorry, the proposed new keyword is 'typecheck' not 'keycheck'. Alan On Monday, September 10, 2018 at 6:01:12 PM UTC+1, alanfo wrote: > > I've revised my feedback on this topic yet again in the light of > criticisms made by Ian which I thought were justified. > > Briefly, I'm now proposing that t

Re: [go-nuts] Re: [ANN] goey - Declarative, cross-platform GUIs

Hello, There isn't a porting guide, but I can provide some guidance. 1) In goey/base, copy widget_linux.go to widget_darwin.go to create stubs for Control and NativeElement, but don't worry about any implementation yet. 2) In goey, temporarily remove all of the files for the controls. You ne

[go-nuts] The generics draft proposal underspecifies contracts

Two thoughts about the contracts proposal: - In the proposal a contract is loosely defined as the resulting implications from a function. In the interests of starting a discussion, it seems like a great starting place. However, it feels like it would be useful to spell it out in the

Re: [go-nuts] Re: Generics as builtin typeclasses

I've revised my feedback on this topic yet again in the light of criticisms made by Ian which I thought were justified. Briefly, I'm now proposing that there should only be one additional contextual keyword 'keycheck' though a number of other changes have been made to fit in with this. The li

Re: [go-nuts] Re: Link: Getting specific about generics

also...if you want to get really specific...for float32 and float64, x==x may not be true. (NaNs) On Mon, Sep 10, 2018 at 7:02 AM Jonathan Amsterdam wrote: > >> The problem is that the spec says that the operands of == have to be the >> same type >> > > Correction: one operand must be assignable

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sun, Sep 9, 2018 at 12:46 AM Ian Lance Taylor wrote: > To me contracts aren't implicit or roundabout at all, at least not > when it comes to which types they permit. They are very direct and > straightforward, and they really could not be simpler. But clearly > many people disagree. Perhaps

[go-nuts] Re: Is it needed to close a HTTP request body ?

On Monday, 10 September 2018 17:27:43 UTC+3, Pierre Durand wrote: > > When I learned Go a few years ago, I was told to always defer/close the > HTTP request body, otherwise it will cause a resource leak. > > But today I read this: https://golang.org/pkg/net/http/#Request.Body > // The Se

Re: [go-nuts] Is it needed to close a HTTP request body ?

OK ! thanks. Le lundi 10 septembre 2018 16:39:28 UTC+2, Sam Whited a écrit : > > > > On Mon, Sep 10, 2018, at 09:27, Pierre Durand wrote: > > When I learned Go a few years ago, I was told to always defer/close the > > HTTP request body, otherwise it will cause a resource leak. > > > > But toda

Re: [go-nuts] Is it needed to close a HTTP request body ?

On Mon, Sep 10, 2018, at 09:27, Pierre Durand wrote: > When I learned Go a few years ago, I was told to always defer/close the > HTTP request body, otherwise it will cause a resource leak. > > But today I read this: https://golang.org/pkg/net/http/#Request.Body > // The Server will clo

[go-nuts] Is it needed to close a HTTP request body ?

When I learned Go a few years ago, I was told to always defer/close the HTTP request body, otherwise it will cause a resource leak. But today I read this: https://golang.org/pkg/net/http/#Request.Body // The Server will close the request body. The ServeHTTP // Handler does not nee

Re: [go-nuts] A thought on contracts

Good point. We will definitely want a warning before inadvertently changing the contract... On Friday, 7 September 2018 10:58:51 UTC-4, Tristan Colgate wrote: > > You lose the ability to see changes of contract in your diff (which I > think is the thing I most want). > > > On Fri, 7 Sep 2018

[go-nuts] Re: Link: Getting specific about generics

> > > The problem is that the spec says that the operands of == have to be the > same type > Correction: one operand must be assignable to the type of the other. The example still stands: you can't compare an int and a float64. -- You received this message because you are subscribed to the

[go-nuts] Re: Link: Getting specific about generics

>From the blog post: For example there could be an eq interface that’s equivalent to a contract > with an x == x. Actually, there can't. If eq were an interface, then func f(x, y eq) bool { return x == y } would be legal. And so would the call var a int var b float64 f(a,

Re: [go-nuts] Re: Generics as builtin typeclasses

On Sunday, September 9, 2018 at 3:52:24 AM UTC-4, Ian Lance Taylor wrote: > > On Sat, Sep 8, 2018 at 7:53 PM, Jonathan Amsterdam > > wrote: > >> When is it important to not just express what operations are > >> required for a type, but also to try to rule out some types? > > > > > I thin

[go-nuts] Golang, how dare you handle my checks! (Critique of error proposal)

"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 Upvote it on Hacker News :-) https://news.ycombinator.com/item?id=17951511 -- You received this message because you are su

Re: [go-nuts] A thought on contracts

On Thursday, 6 September 2018 23:22:34 UTC+3, Ian Lance Taylor wrote: > > On Wed, Sep 5, 2018 at 8:26 PM, Steve Phillips > wrote: > > Interesting idea, but has the Go team expressed interest in creating > such a tool? > > Yes, I think it's become clear that we should have a tool that, given

Re: [go-nuts] Re: Generics as builtin typeclasses

You're right, I apologize. It not only wasn't nice, it also was an ineffective way to make my point. So let me try to make that point as clearly as I can. You and many others have tried to replace contracts with interfaces. But if generics are to have operator constraints like T == T, then some

Re: [go-nuts] Re: Generics as builtin typeclasses

Sorry to have duplicated your idea, rog, particularly as I did read your feedback what now seems "years" ago! Frankly, there has been so much feedback and so may lengthy threads on this topic that I'm losing track of what's been suggested and by whom :( Alan On Monday, September 10, 2018 at 10

Re: [go-nuts] Modules + go get

Yes I think defaulting to go get -u without modules is best too. Because modules allow version compatibility, and so code intended for use with modules may not work at the repo HEAD, asking go get to fetch without building may be more reliable. Best, Scott On Monday, 10 September 2018 11:00:47

Re: [go-nuts] Modules + go get

>> GO111MODULE=off go get -u github.com/my/package > > Last time I check, if GOPATH is unset and GO111MODULE is on it will download > the source code to $HOME/go. If you saw this behaviour then that is a bug. Or did you mean GO111MODULE=auto or GO111MODULE is unset (in addition to GOPATH being un

Re: [go-nuts] Re: Generics as builtin typeclasses

On 10 September 2018 at 09:46, wrote: > I don't know whether anyone has suggested this before but why not disallow > direct method calls on a contract's type arguments altogether and force > people to use interfaces instead? I suggested that here FWIW: https://gist.github.com/rogpeppe/45f5a75785

Re: [go-nuts] Modules + go get

On Mon, 10 Sep 2018, 16:00 Paul Jolly, wrote: > > GO111MODULE=off go get -u github.com/my/package > Last time I check, if GOPATH is unset and GO111MODULE is on it will download the source code to $HOME/go. -- You received this message because you are subscribed to the Google Groups "golang-nu

Re: [go-nuts] SQL Interceptor

Sure point, I also have doubts about modifying the request on-the-fly. >From the point of "accessing an external system" it is similar and I'd even be in favour of a generic tracing/timing mechanism for *anything* that needs I/O or is otherwise subject to latency jitter. Perhaps widening the scope

Re: [go-nuts] SQL Interceptor

It's worth considering that gRPC interceptors are not passive participants in gRPC requests. They can actively modify the requests, and responses (e.g. to enforce authentication). It's not obvious what that would look like for SQL, or if that is even desirable. There is a pre-existing db/sql issu

Re: [go-nuts] Modules + go get

This sort of "global" get/install is being discussed in https://github.com/golang/go/issues/24250 (which will also cover the documentation point). It's marked as "release blocked" for Go 1.12. For now, I think the best approach is to: GO111MODULE=off go get -u github.com/my/package i.e. drop bac

[go-nuts] Re: Generics as builtin typeclasses

In the draft design paper it says: "There are a few aspects to a method call that can not be shown in a simple assignment statement like the ones shown above. There is no way to specify that a method does not return any values. There is no way to specify that a method takes variadic argu

[go-nuts] Modules + go get

What's the best substitute for "go get my/tool" in a modules world? I used to be able to tell my users to set up Go with a GOPATH workspace and then run "go get -u github.com/my/package". I can't find an equivalent workflow now. The closest I can find is GOBIN=~/bin GO111MODULES=on go get github.

Re: [go-nuts] SQL Interceptor

On Mon, 2018-09-10 at 09:05 +0100, Tristan Colgate wrote: > There are two existing projects used to achieve similar goals: > > https://github.com/ExpansiveWorlds/instrumentedsql > https://github.com/gchaincl/sqlhooks > > native support could probably improve things a little, but this is a > very

Re: [go-nuts] SQL Interceptor

There are two existing projects used to achieve similar goals: https://github.com/ExpansiveWorlds/instrumentedsql https://github.com/gchaincl/sqlhooks native support could probably improve things a little, but this is a very reasonable approach. On Mon, 10 Sep 2018 at 08:59 Conrad Wood wrote:

Re: [go-nuts] Re: Generics as builtin typeclasses

On Mon, Sep 10, 2018 at 12:47 AM Randall O'Reilly wrote: > WRT the objection of introducing a bunch of new keywords to explicitly > specify what is otherwise indirectly specified by contracts, there is > already a full explicit list of such things in the reflect.Kind type. > Could we not just use

Re: [go-nuts] SQL Interceptor

On Mon, 2018-09-10 at 09:44 +0200, Jan Mercl wrote: > > On Mon, Sep 10, 2018 at 8:16 AM Conrad Wood > wrote: > > > Wdyt? Is that a patch that would be acceptable and generally > useful? > > It could be tried and evaluated first as an external package. > > --  > -j Not sure I understand. The p

Re: [go-nuts] SQL Interceptor

On Mon, Sep 10, 2018 at 8:16 AM Conrad Wood wrote: > Wdyt? Is that a patch that would be acceptable and generally useful? It could be tried and evaluated first as an external package. -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To