Re: [go-nuts] Regarding contracts

If you require that a single like type applies to all the labels in the parameter declaration, such that func f(a, b T like int, c, d T2 like string) means a and be must be like T's instantiating type, and c and d must be like T2's unstantiating type, then you get that. If you only require a singl

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

After reading his proposal, I think you should help Burak Sedar work out his proposal in the other thread. It is conceptually a lot easier than the idea of contracts, but likely to be more powerful even. To me it has the ideal Go-like feel and it solves the problem with operator overloading in

[go-nuts] Re: Regarding contracts

After all the discussions about contracts, this is a refreshing new idea that is conceptually far simpler. Sure the details need to be worked out, maybe with a somewhat different syntax, but it seems far better than the idea of contracts indeed. A type is a "contract" in itself, and a primitive

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

This is only tangentially related to your specific idea, but I've decided that for generics discussions this is the hill I'm dying on: On Wed, Oct 17, 2018 at 6:44 PM roger peppe wrote: > The method calls in question can be inlined because everything is known > statically, so there's theoretical

Re: [go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

I don't think you even need contracts as such at this point; you can do a cast without them, so you just need to be able to specify a method set on type parameters. I would be interested to hear your thoughts on the proposal I wrote up on how to do this: https://gist.github.com/zenhack/ad508d0

Re: [go-nuts] Feedback from Stripe developers on Go 2 draft designs

Thanks for the feedback. Please do add these notes to the wikis as discussed at https://go.googlesource.com/proposal/+/master/design/go2draft.md . Thanks. Ian On Wed, Oct 17, 2018 at 3:13 PM, Aditya Mukerjee wrote: > Recently, several developers at Stripe who write Go regularly for their work >

[go-nuts] Re: Feedback from Stripe developers on Go 2 draft designs

Hi, thanks for posting this! > *Is `defer check f.Close()` valid?* *No, because the defer stack would run after the final handle block.* *I describe handlers within the defer stack in Requirements to Consider for Go 2 Error Handling* *https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7

Re: [go-nuts] go-grpc question

On Wed, Oct 17, 2018 at 5:04 PM wrote: > Hi Josh, > > Thanks for getting back ! Wouldn't having a single TCP connection be a > bottleneck (assuming no layer-4 load balancer) especially if there is a > slow reader, tcp flow control would limit other streams on that connection. > In that case would

[go-nuts] Feedback from Stripe developers on Go 2 draft designs

Recently, several developers at Stripe who write Go regularly for their work met to discuss the Go 2 design drafts for error handling, error values, and generics. The goal of the meeting was *not* necessarily to provide a single conclusion on each of the design drafts, but

[go-nuts] Go App Engine 1.11 Multithreaded?

Hello Gophers! Does anybody know if the new Go 1.11 App Engine Standard Environment lift the 1 thread limit previously set for the first generation environment? Although Concurrency is not Parallelism, a little of both wouldn't hurt? ;) -- You received this message because you are subscribed t

Re: [go-nuts] Regarding contracts

I think there are serious issues with your syntax for functions and “templates.” For example, there doesn’t seem to be a way to specify that two parameters to a function need to be the same type, or that the return type will be the same as the parameter. The syntax from the official proposal is

Re: [go-nuts] Having trouble installing golint

TL;DR — you don't need to run the second command, just the first one. I'm sorry for being unclear. Go get looks up packages by their import path. The import path of golint is "golang.org/x/lint/golint", so the second command you ran with the github URL will never work since that is the repo, not

Re: [go-nuts] go-grpc question

Hi Josh, Thanks for getting back ! Wouldn't having a single TCP connection be a bottleneck (assuming no layer-4 load balancer) especially if there is a slow reader, tcp flow control would limit other streams on that connection. In that case wouldn't having more connections help ? Thanks, Nakul

Re: [go-nuts] Having trouble installing golint

Why do you think the first command (at golang.org) failed? Looks like everything worked to me. On Wednesday, October 17, 2018 at 3:48:05 PM UTC-4, kalekold wrote: > > I've already tried that and the original command still fails. > > $ go get -u -v golang.org/x/lint/golint > Fetching https://golan

Re: [go-nuts] Regarding contracts

On Wed, Oct 17, 2018 at 1:47 PM Andy Balholm wrote: > > That’s a very interesting idea. It would probably need to be extended to > allow specifying that a type is like multiple types. Then the effective > “contract” would be the intersection of the operations provided by those > types. For exam

[go-nuts] Template function arguments from JS

Hi! I have some template which gets populated based on some function, but the latter gets an argument from javascript code, defined in the same template. Of course, it doesn't work, as js code doesn't get executed within the template context. Code is as follows: function getMonth() {

[go-nuts] [ANN] RAIS image server 3.0.0: high-performance IIIF server (think deepzoom combined with dynamic cropping and resizing of images)

https://github.com/uoregon-libraries/rais-image-server/wiki/Release-Notes#release-300 I posted about two years ago here about this project, but it's had some massive changes since then. Briefy, RAIS is a IIIF-compliant image server (see iiif.io). It conforms to level 2 of the IIIF Image API 2.

Re: [go-nuts] Generics: an unwelcome conclusion and a proposal

* Ian Lance Taylor [181016 17:59]: > The contract system in the generics design draft does not have this > problem. It may have other problems, but it doesn't have this one. I haven't finished reading the draft (I got to the beginning of the Contract Details section when it was first mentioned o

Re: [go-nuts] Having trouble installing golint

I've already tried that and the original command still fails. $ go get -u -v golang.org/x/lint/golint Fetching https://golang.org/x/lint/golint?go-get=1 Parsing meta tags from https://golang.org/x/lint/golint?go-get=1 (status code 200) get "golang.org/x/lint/golint": found meta tag get.metaImport

Re: [go-nuts] Regarding contracts

That’s a very interesting idea. It would probably need to be extended to allow specifying that a type is like multiple types. Then the effective “contract” would be the intersection of the operations provided by those types. For example, we would want to be able to specify a type that is like bo

Re: [go-nuts] Regarding contracts

Burak Serdar : > Instead of specifying the minimal set of operations a type should > satisfy, why not describe what the type should look like: I don't know if this can be followed through to a full proposal, but I like the out-of-the-box thinking. -- http://www.catb.org/~esr/";>Er

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Patrick Smith : > If I understand correctly, you would make a copy of the entire list in > order to be able to iterate over it? This seems inefficient. This actually references something that has been a pain point in my Python translation: absence of iterators. I have a very simple idea about how

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Patrick Smith : > Sorry if I was unclear. I wanted to know, not how it could be done under > some other proposal (such as adding methods to built-in types), but how > Alan or Eric would do it in their proposals for operator overloading. I don't see any intrinsic problem with allowing "implements [

[go-nuts] Regarding contracts

Disclaimer: I don't work on languages. I just don't like the idea of writing contracts. Instead of specifying the minimal set of operations a type should satisfy, why not describe what the type should look like: func f(in like T) This means 'in' should be a type that has all the operations defin

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Yes, that's a fair point. As I was wobbling anyway, I'll give way on that one :) Alan On Wednesday, October 17, 2018 at 6:47:25 PM UTC+1, Patrick Smith wrote: > > On Wed, Oct 17, 2018 at 3:13 AM alanfo > > wrote: > >> On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote: >>>

[go-nuts] Operators in interfaces

Warning: yet another generics-related idea ahead. :-) The motivation for using contracts instead of interfaces as the type constraints in the Go 2 generics proposal is the fact that interfaces only allow one type of operation: method calls. And we’d like to be able to use other operations, such

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Wed, Oct 17, 2018 at 3:13 AM alanfo wrote: > On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote: >> >> If overloading [] were disallowed, how would one write a generic function >> taking a single argument of type either []int or a user-defined type with >> similar behavio

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tue, Oct 16, 2018 at 5:44 PM robert engels wrote: > The easiest solution is that []int IS A IntList by definition, no ? > Meaning that an “slice” has defined methods Len(), and At(). I would > personally define other methods on slice too for convenience (like, Insert, > Delete). The [] notatio

Re: [go-nuts] Does client.go#transport() reuse s global DefaultTransport when http.Client's Transport is nil?

On Wed, Oct 17, 2018 at 11:13 AM Kyle Butz wrote: > > Thanks for the help! > > So, a copy of the pointer to the Transport used to initialize > DefaultTransport would be the same, global instance of the Transport? > > Does that mean that every time I instantiate a new client, I am using the > sam

Re: [go-nuts] Does client.go#transport() reuse s global DefaultTransport when http.Client's Transport is nil?

Thanks for the help! So, a copy of the pointer to the Transport used to initialize DefaultTransport would be the same, global instance of the Transport? Does that mean that every time I instantiate a new client, I am using the same Transport? On Wednesday, October 17, 2018 at 11:35:52 AM UTC-5

Re: [go-nuts] Having trouble installing golint

As the error says, you need to use golang.org/x/lint/golint: go get -u -v golang.org/x/lint/golint —Sam On Wed, Oct 17, 2018, at 10:12, gary.willoug...@victoriaplumb.com wrote: > I'm having trouble installing golint. Any idea what the problem could be? > > $ go get -u -v github.com/golang/l

[go-nuts] relaxing type conversions: an "almost possible" idea with Go generics

While thinking about the draft generics proposal and the complexity of contracts, it occured to me that if you relax some of the restrictions on type conversion, it's possible to make data structures containing basic types amenable to generic algorithms. Once upon a time, the Go specification allo

Re: [go-nuts] Does client.go#transport() reuse s global DefaultTransport when http.Client's Transport is nil?

On Wed, Oct 17, 2018 at 10:30 AM Kyle Butz wrote: > > Hi All! > > I'm having trouble understanding whether a new http.Client{} with no > Transport set will use a new copy of DefaultTransport, or the global? > > From client.go: > > func (c *Client) transport() RoundTripper { >if c.Transport !=

[go-nuts] Does client.go#transport() reuse s global DefaultTransport when http.Client's Transport is nil?

Hi All! I'm having trouble understanding whether a new http.Client{} with no Transport set will use a new copy of DefaultTransport, or the global? >From client.go: func (c *Client) transport() RoundTripper { if c.Transport != nil { return c.Transport } return DefaultTransport }

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Wednesday, October 17, 2018 at 11:12:19 AM UTC-4, Ian Denhardt wrote: > > My instinct here is to be conservative; we've got a boatload of use > cases for < and ==, a few obvious ones for +, *, / etc, and a long-tail > for operators after that. Eric's proposal makes it trivial to add more >

Re: [go-nuts] Go language should become an ANSI and ISO standard.

I think standards have a tendency to end up failing to be standard because of a plethora of standards, the need to make optional parts which render the standard impractical for basic tasks (eg open al), the fact that large market interests tend to have their own version (eg open SL ES android),

[go-nuts] Having trouble installing golint

I'm having trouble installing golint. Any idea what the problem could be? $ go get -u -v github.com/golang/lint/golint github.com/golang/lint (download) package github.com/golang/lint/golint: code in directory /home/gary/Code/go/ src/github.com/golang/lint/golint expects import "golang.org/x/lint/

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Quoting Patrick Smith (2018-10-16 19:21:35) >If overloading [] were disallowed, how would one write a generic >function taking a single argument of type either []int or a >user-defined type with similar behavior, and returning the sum of the >elements? Sort of the marriage of these

Re: [go-nuts] spanish tour.golang.org is down

On Wed, 17 Oct 2018 06:49:09 -0700 Ian Lance Taylor wrote: > On Wed, Oct 17, 2018 at 1:29 AM, Gorka Guardiola > wrote: > > > > Other languages seem to be ok. > > The link has been down with a 404 error for quite some time. > > Does anybody know why? > > I don't know but it's been down for a w

Re: [go-nuts] spanish tour.golang.org is down

On Wed, Oct 17, 2018 at 1:29 AM, Gorka Guardiola wrote: > > Other languages seem to be ok. > The link has been down with a 404 error for quite some time. > Does anybody know why? I don't know but it's been down for a while: https://github.com/golang/tour/issues/596 . Francesc, any idea who owns

Re: [go-nuts] go-grpc question

*+grpc...@googlegroups.com * *moving golang-nuts@googlegroups.com to BCC* In general, connections are not cheap, but stubs are. Actual implementations for some languages differ, but Go complies with this. What that means is that, generally speaking, you should not try creating the *grpc.ClientC

[go-nuts] spanish tour.golang.org is down

Other languages seem to be ok. The link has been down with a 404 error for quite some time. Does anybody know why? Thanks, G. -- - curiosity sKilled the cat -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and st

Re: [go-nuts] Remove path from error messages

That is what I was looking for!! Thanks!! On Tue, Oct 16, 2018 at 4:16 PM Ian Lance Taylor wrote: > On Tue, Oct 16, 2018 at 11:57 AM, Rich wrote: > > Hi and Thanks Peter for your reply! I have compiled this on my mac, and > am > > running it on a linux system. I compile it like this: > > > >

[go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Tuesday, October 16, 2018 at 6:05:56 PM UTC+1, Eric Raymond wrote: > > > > On Tuesday, October 16, 2018 at 12:24:59 PM UTC-4, alanfo wrote: >> >> With regard to your reply to Ian, I'm afraid I can't agree with you that >> the type parameters shouldn't be specified 'up front'. That's just too >

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

Operator overloading seems completely antithetical to what most seem to value in Go. Readability is key. Go mostly avoids syntactic sugar (and where it has it, it is often acknowledged as a mistake). To me, the existing contracts design makes it clear when a generic is being used. It should also

Re: [go-nuts] Re: Generics: an unwelcome conclusion and a proposal

On Wednesday, October 17, 2018 at 12:22:15 AM UTC+1, Patrick Smith wrote: > > On Tue, Oct 16, 2018 at 3:33 AM alanfo > > wrote: > >> I would also disallow overloading of the =, :=, <-, ..., [], {}, () and >> yes - equality operators - as well because I believe to do otherwise would >> be very co

[go-nuts] Re: go-grpc question

c) gRPC (at least the Go library) handles the connection/reconnection automatically - you can provide your own Dial if you want something fancy/non-standard (HTTP connection, connection through pipes or domain sockets...) -- You received this message because you are subscribed to the Google G

Re: [go-nuts] sync/mutex locking race condition issues

On Wed, Oct 17, 2018 at 8:37 AM wrote: Hi, I am having issues with some concurrency and race conditions. > I believe this is not doing what I think it does. IE I am thinking this would allow locking of any variable in the struct however it does not seem to be applying to buffer of type bytes.