[go-nuts] Re: http client POST/GET.. will not save cookie before do redirect request

On Wednesday, 12 September 2018 06:28:12 UTC+2, Weeds Qian wrote: > > What did you expect to see? > > the cookie in response > What did you see instead? > > no cookie in response > > > --http tcp stream from wireshark > - > > You can see that I only do t

[go-nuts] Go memory usage inside containers

Hi, Does anyone here know how Go interacts with memory limits inside containers? (e.g. Kubernetes, Docker) Does the Go runtime have similar problems as the Java runtime, in that it doesn't know what the container limit is, and only knows what the physical limit is for the entire instance? Or

[go-nuts] I want to run a go project called syncthing on iOS , but I have some issues

Why not just "go install" ? -- 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.googl

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

On Tuesday, 11 September 2018 18:28:29 UTC+3, Robert Engels wrote: > > > On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts < > golan...@googlegroups.com > wrote: > > [golang-nuts to CC, golang-dev to BCC] > > On Mon, Sep 10, 2018 at 5:33 PM robert engels > wrote: > >> In the entire code

[go-nuts] I want to run a go project called syncthing on iOS , but I have some issues

*I run the shell * *set -eecho "Done 1"* *HOME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"GO=$HOME/golang/bin/go* *if [ ! -d "$HOME/cgo-obj" ]; thenmkdir $HOME/cgo-objfi* *if [ ! -d "$HOME/go-obj" ]; thenmkdir $HOME/go-objfi* *echo "Done 2"CGO_ENABLED=1 GOARCH=arm64 GOA

[go-nuts] http client POST/GET.. will not save cookie before do redirect request

go version go1.10.3 linux/amd64 *What did you do?* Simply do http POST request, I want to login with http client to the server https://github.com/qianguozheng/goadmin.git, but it not work out. If possible, provide a recipe for reproducing the error. A complete runnable program is good. A link o

Re: [go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

On Sep 11, 2018, at 3:02 PM, Ian Lance Taylor wrote: > > I'll just note briefly that I tossed field accessors in the contracts > design draft because it was easy, not because I thought it was an > important feature. It would be interesting to see a real use case for > it. At this point I would

[go-nuts] Generics - Min challenge

This is a hypothetical question. Suppose generics were implemented as in the draft proposal, but without contracts. Instead, the rule is that if an instantiation of a generic function with a specific type argument doesn't compile, then it can't be used. Under those circumstances, is there any way

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

On Tue, Sep 11, 2018 at 6:56 AM wrote: > 2. An initialized type cannot be used directly as a method receiver, it > must be type-aliased first: > type FooInt = Foo(int) > func (fi FooInt) Bar() {} // no type parameters now so clearly a > method of FooInt > ... > Another problem is whether

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

On Tue, Sep 11, 2018 at 10:45 AM Ian Lance Taylor wrote: > On Tue, Sep 11, 2018 at 10:04 AM, roger peppe wrote: > >> func (x Foo(int)) Bar() {} > > > > As I understand it, this would be technically allowed, but would not > > mean what you think. > > Yes. > Ouch! I chose a poor example. I think

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

On Tue, Sep 11, 2018 at 5:46 PM, Ian Lance Taylor wrote: > > While methods can be a convenient way to organize code, their only > real semantic meaning is to satisfy interfaces. They also represent a limited form of type-directed function overloading. A package can contain multiple methods with

Re: [go-nuts] Generics - Why contracts?

Correction: you'd only need 3 additional built-ins as 'real' is already used to find the real part of a complex number. Although it would be used differently here, you might want to use 'numeric' instead to avoid confusion. Alan On Tuesday, September 11, 2018 at 11:31:03 PM UTC+1, alanfo wrote

Re: [go-nuts] Generics - Why contracts?

Robert, I suspect that you could achieve 90% coverage with just 4 built-in contracts: 1. integer (any integer type) 2. real (any integer or floating point type) 3. ordered (any integer, floating point or string type) 4. comparable (any type which supports == and !=) If you had just one t

Re: [go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

On Tue, Sep 11, 2018 at 2:56 AM, 'Axel Wagner' via golang-nuts wrote: > > * My post does not allow to constrain on struct fields. This is a > fundamental reduction in power over contracts (type-parameters can't be > identifiers, but only type names so can't solve this like > assignability/converti

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

And BTW, when you use Golang 1.11 you should definitely look into using „go mod“ for dependencies which offers pip freeze and pip install -r. The good thing is, that you do not need to symlink your project into the GOPATH then :-) -- You received this message because you are subscribed to the G

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

On 11 September 2018 at 22:46, Ian Lance Taylor wrote: > On Tue, Sep 11, 2018 at 1:39 PM, roger peppe wrote: >> On 11 September 2018 at 18:04, roger peppe wrote: >>> If it were not explicitly prohibited by the draft proposal, we could >>> also imagine this, a definition of a method foo on the ty

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

On 11 September 2018 at 22:17, jimmy frasche wrote: > I think it would work with interfaces if the interfaces (generic or > not) can themselves specify generic methods, like > > interface { > Foo(type T)(T) T > } The problem with that is, as is pointed out in the draft proposal, that if you all

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

Hello Eric, if you host your project at gitlab.com, you may use any Docker image available at the standard docker hub, e.g. https://hub.docker.com/_/golang/ Depending on whether you choose the alpine or Debian based image, you may easily install Python, this is in my experience less cumbersome

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

On Tue, Sep 11, 2018 at 1:39 PM, roger peppe wrote: > On 11 September 2018 at 18:04, roger peppe wrote: >> If it were not explicitly prohibited by the draft proposal, we could >> also imagine this, a definition of a method foo on the type A that's >> parameterised with type T; the method itself h

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

I think it would work with interfaces if the interfaces (generic or not) can themselves specify generic methods, like interface { Foo(type T)(T) T } You need to be able to invoke methods on a generic type where the method is not specialized for the instantiation so I don't see why it should cau

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

Can't say I've a strong feeling one way or another on that though there'd be an awful lot of brackets if it were allowed! You can, of course, always work around it with a top level function: func foo(type S, T)(a A(T), s S, t T) On Tuesday, September 11, 2018 at 9:39:23 PM UTC+1, rog wrote: >

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

That'd mean more difference between parametrized and non generic types, which causes more confusion than good. -- 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 g

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

On 11 September 2018 at 18:04, roger peppe wrote: > If it were not explicitly prohibited by the draft proposal, we could > also imagine this, a definition of a method foo on the type A that's > parameterised with type T; the method itself has a type parameter S: > > func (a A(T)) foo(type S)(s

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

Yes, adding methods to instantiated generic types would have some similarities to (partial) template specialization in C++. Having concluded that it was a bad idea anyway from the earlier discussion, I'm glad it's not going to be allowed :) On Tuesday, September 11, 2018 at 6:45:29 PM UTC+1, I

Re: [go-nuts] Generics - Why contracts?

alan.f...@gmail.com : > The problem is that many of us don't find the sort of code used in > contracts (as currently envisaged) to be 'normal' at all and we're worried > that the Go community at large will find them difficult to write (though a > tool may help), understand or use. What you've ju

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

On Tue, Sep 11, 2018 at 10:04 AM, roger peppe wrote: >> func (x Foo(int)) Bar() {} > > As I understand it, this would be technically allowed, but would not > mean what you think. > > This is defining a method Bar on the Foo type, and "int" is declaring > a name for the type parameter defined in t

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

There are two parts to interfaces. The interface value—the box that things are stored in at runtime. The interface type—the specification for what things you are allowed to put in that box at compile time. Using the interface type to constrain type parameters at compile-time does not necessarily

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

> func (x Foo(int)) Bar() {} As I understand it, this would be technically allowed, but would not mean what you think. This is defining a method Bar on the Foo type, and "int" is declaring a name for the type parameter defined in the definition of Foo. That name would shadow the global language

Re: [go-nuts] Generics - Why contracts?

Having an external tool to write/validate contracts sounds more like a hack than a proper solution. It's kind of the same reason why I dislike generators. You have to learn an "alien" syntax that doesn't quite fit the rest of the language. If we are going that way, why not implement a full fledged

Re: [go-nuts] Generics - Why contracts?

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 - intentionally - and it’s a good choice. > On Sep 11, 2018, at 11:22 AM, alan.f...@gmail.com wrote: >

Re: [go-nuts] Generics - Why contracts?

There is one thing which I think is quite clear from all the discussions that have taken place on this topic. Having withstood years of criticism for the lack of generics in Go, the team are not going to be satisfied now with some under-powered or half-baked solution. They want to have as much

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

I only brought up LOC from the stand point that a 10 line program is most likely trivial to maintain. A million line program in any language is a different beast, and some are better suited for that “size” I agree with you whole heartedly that Go and Java are different beasts. I wasn’t a fan of

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

+ 1,000,000 > > > Exactly, Go is very simple, and ideal for the cases I pointed out in the > original post (and I’ll add, micro-services too), and so far all of the > proposals that seem to be gaining traction don’t continue that design > paradigm. > > -- You received this message because you ar

Re: [go-nuts] Generics - Why contracts?

On Tuesday, September 11, 2018 at 11:35:05 AM UTC-4, Ian Davis wrote: > > > Recent conversations here and around the proposal suggest that the type > system isn't strong or clear enough to convey the kinds of constraints that > we want to use. Personally I am not a fan of having nonsense, unexec

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

On Tue, Sep 11, 2018 at 5:28 PM robert engels wrote: > This seems to contradict this a bit, > https://stackoverflow.com/questions/41586501/why-is-kubernetes-source-code-an-order-of-magnitude-larger-than-other-container > but > it may be an indictment that Go’s lack of classes/inheritance/generic

Re: [go-nuts] "GOPATH" set but "go get" downloads to ~/go

Ok, this might be it for one case. I'll check again tomorrow. On Tue, Sep 11, 2018, 8:55 PM Borman, Paul wrote: > Silly question, but is it exported? You can easily check with the > command: > > env | grep GOPATH > > -Paul > > On Sep 11, 2018, at 9:30 AM, Sathish VJ wrote: > > I saw this behav

Re: [go-nuts] Generics - Why contracts?

On Tue, 11 Sep 2018, at 3:23 PM, Jeff wrote: > TLDR; So why contracts and not templates or something else? Is there > a benefit to contracts that I don't appreciate (very likely, cause I > don't understand them)? Are there issues with a template approach? > If this has been addressed elsewhere, p

Re: [go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

> On Sep 11, 2018, at 9:55 AM, 'Axel Wagner' via golang-nuts > wrote: > > [golang-nuts to CC, golang-dev to BCC] > > On Mon, Sep 10, 2018 at 5:33 PM robert engels > wrote: > In the entire codebase of Docker I could find only one obvious use of > interface{}, and

Re: [go-nuts] "GOPATH" set but "go get" downloads to ~/go

Silly question, but is it exported? You can easily check with the command: env | grep GOPATH -Paul On Sep 11, 2018, at 9:30 AM, Sathish VJ mailto:sathis...@gmail.com>> wrote: I saw this behavior with a couple of Mac machines today and I was unable to debug it. Just checking to see if it is a

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

On Tue, Sep 11, 2018 at 4:39 PM Larry Clapp wrote: > Directly accessing a field in a generic struct might be *rare*, but it > seems like it shouldn't be *impossible*. > I think it would be better if it is, but if it introduces additional cost, that cost needs to be weighed against the benefit :)

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

On Tuesday, September 11, 2018 at 9:24:56 AM UTC-4, Larry Clapp wrote: > > This question frankly struck me odd, given the context. To paraphrase: > "Do I have examples of where accessing a field in a generic struct type > might be useful?" I kind of assumed that, hip-deep as we are in a > di

[go-nuts] Generics - Why contracts?

I am a semi-advanced hobbyist. I have a BSCEE degree, but no professional programming experience. I have been programming for > 30 years and have written small programs in easily 20+ different languages during that time. So, while not a professional programmer, I am not exactly a novice. I've

[go-nuts] Re: [golang-dev] go doesn't need generics, but if they do...

[golang-nuts to CC, golang-dev to BCC] On Mon, Sep 10, 2018 at 5:33 PM robert engels wrote: > In the entire codebase of Docker I could find only one obvious use of > interface{}, and no type casts. > Generics are not only useful for functions taking interface{}. They are also useful for functio

Re: [go-nuts] Setting font in draw2d

Thanks, I Will give that packade a try instead. -- 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, visi

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

Generics itself is a form of overloading, albeit in a very narrow sense. A generic function is in effect a set of functions (often infinite) where all the type parameters are replaced by those types which can conceivably satisfy any constraints placed upon them. Anyway, assuming for the moment

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

Hi, Axel, You're certainly right: we can *get around* not having access to specific fields in generic functions. And my MinKeys example may've been suboptimal, or not a great example to begin with. And the fact that you have to hard-code the field name(s) to be accessed in the contract also s

[go-nuts] Re: "GOPATH" set but "go get" downloads to ~/go

Wanted to add that both had go 1.11 installed. Downloaded as a zip/gz file and extracted to a known path. Also, there were 20+ others also there who did the same, but did not face that issue. But we were unable to figure out the root cause. On Tuesday, 11 September 2018 20:00:53 UTC+5:30, Sath

Re: [go-nuts] Setting font in draw2d

On Tue, 11 Sep 2018, at 3:01 PM, viktor.oge...@gmail.com wrote: > Hi, > > I am struggling to load and use custom fonts from ttf files in draw2d > (used since I need rotated text).> > To illustrate: https://play.golang.org/p/6-rswetZOr8 give the output:> > 2018/09/11 15:52:43 open ../resource/fon

[go-nuts] "GOPATH" set but "go get" downloads to ~/go

I saw this behavior with a couple of Mac machines today and I was unable to debug it. Just checking to see if it is a known issue. Macbook 1: GOPATH is set to a known location (verified with echo $GOPATH) and it matches what is shown in "go env" do "go get github.com/username/pkgname" on comman

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

On Tue, Sep 11, 2018 at 12:51 PM alanfo wrote: > Whilst you're correct that parameterized types can have methods, I don't > see any reason why instantiated types can't have methods as well, just like > any 'normal' concrete type. > It could, if you're willing to go down the rabbit-hole of overlo

[go-nuts] Setting font in draw2d

Hi, I am struggling to load and use custom fonts from ttf files in draw2d (used since I need rotated text). To illustrate: https://play.golang.org/p/6-rswetZOr8 give the output: 2018/09/11 15:52:43 open ../resource/font/luxisr.ttf: no such file or directory It seems as if GraphicsContext.SetFo

Re: [go-nuts] Why GO do not have implemetion of algorithm ECIES

https://www.google.com/search?ei=AsqXW9-zEIfc8APmmJ_oBA&q=ecies+golang&oq=ECIES+go&gs_l=psy-ab.1.0.0j0i22i30j0i22i10i30.39647.40358..42045...0.0..0.132.299.1j2..01..gws-wiz...0i71j0i20i263j0i67.6G44ZqkH1sA On Tue, Sep 11, 2018 at 4:46 AM Ally Dale wrote: > Hi everyone, > I'm interest

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

I've been thinking some more about this and, assuming that Patrick and I are right that an instantiated type can have its own method set, there are going to be some severe ambiguities when defining generic functions i.e. it's not always going to be clear whether T is a type parameter or an actu

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

Hi Larry, On Tue, Sep 11, 2018 at 3:25 PM Larry Clapp wrote: > This question frankly struck me odd, given the context. To paraphrase: > "Do I have examples of where accessing a field in a generic struct type > might be useful?" I kind of assumed that, hip-deep as we are in a > discussion of ge

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

On Tue, Sep 11, 2018 at 1:54 PM Tristan Colgate wrote: > It feels like, so far, all of the attempts to simplify the original design > wind up looking more complicated for little benefit (and reduced > functionality). > There is no accounting for taste, of course, but I wildly disagree. In partic

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

This question frankly struck me odd, given the context. To paraphrase: "Do I have examples of where accessing a field in a generic struct type might be useful?" I kind of assumed that, hip-deep as we are in a discussion of generic functions, that such a thing might be understood? I mean, acc

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

Hello, I've taken a previous comment about screenshots seriously. They will be up in a little bit. The layout widgets are actually all platform-independent. Initially, I was relying on the layout widgets in GTK, but it was too hard to get feature parity. For a OSX port, layout will be easy,

[go-nuts] Re: Possible issue in contracts proposal

I think you're right that (assuming x isn't a pointer type), the following would tell the compiler that 'String() string' is a value method of T. contract stringer(x T) { var _ string = T.String(x) } However, in the following case: contract stringerp(x T) { var _ string = (*T).String(&x

Re: [go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

It feels like, so far, all of the attempts to simplify the original design wind up looking more complicated for little benefit (and reduced functionality). Re-using interfaces seems like it would mandate boxing, (or interfaces are no longer interfaces as currently described, which would also be a

[go-nuts] Why GO do not have implemetion of algorithm ECIES

Hi everyone, I'm interesting in why GO do not have implemention of algorithm ECIES. As another kind of PKI algorithm ,EC family has much less key length and supplies more strenth of security to compare with RSA. I want to know if GO team has plans of ECIES or has any suggestions about that? Ally

[go-nuts] Re: Scrapping contracts (was: "Generics as bultin typeclasses")

> > * I think constraining type-parameters to channel/slice/map types might > not be needed at all. Instead of, say "func Foo(type T channelOfBar) (ch > T)", ISTM that we can use "func Foo(ch chan Bar)". Since any channel-type > with element type Bar can be assigned to `chan Bar`, this would al

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

A lot of those just pick out a subset of built-in types (or a type whose underlying type is a built-in). boolean is an obvious example, but arith is just all the numeric types. We already have names for those: int, bool, etc. We just need to combine them with "or". E.g. bool is "underlying(bool

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

Do you have actual examples of how that would be useful to you? On Monday, September 10, 2018 at 9:45:12 PM UTC-4, Larry Clapp wrote: > > 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 prop

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

Well, firstly, I think it would be perfectly reasonable for the compiler to disallow a generic type if one (or more) of its type parameters were not used in the generic type's definition. However, I couldn't see anything about this in the design document itself which is why I said I wasn't sure.

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

On Tue, Sep 11, 2018 at 11:52 AM wrote: > I'm not sure whether this: > >type Foo(type T) struct{} > > would be allowed or not - the compiler might say "type parameter T is not > used". > > Anyway, if it were allowed, then it would follow that these should also be > allowed: > >func f(x Fo

[go-nuts] Scrapping contracts (was: "Generics as bultin typeclasses")

I don't know if fragmenting the conversation will improve or decrease clarify. I also agree that we should primarily focus on the existing generics design by Ian and Robert. So if you find this kind of conversation counter-productive, please ignore :) That being said, I also feel I'll understand th

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

I'm not sure whether this: type Foo(type T) struct{} would be allowed or not - the compiler might say "type parameter T is not used". Anyway, if it were allowed, then it would follow that these should also be allowed: func f(x Foo(int)) {} func (x Foo(int)) Bar() {} and that Foo(in

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

Under the latest version of my own proposal, you'd do it something like this: contract mycont(T) { // ensure T has a field F of whatever type is required (FieldType say) typecheck(T, "struct{F FieldType}") } // sample generic function which takes one parameter and has no return type, s

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

I’m sorry, but I don’t think your reasoning is correct. See the code below. Less lines, and better functionality & design, and you can do this today… (trivial to also add the ComplexPrice) Although I think you should be able to write: ip := Prices{1,2,3} and the compiler could figure out that