[go-nuts] Re: handling unexpected module path

[thepudds1460]

Joe,

There's a good chance your diagnosis is correct -- my understanding is the 
path used in an import statement is required to match up with the module 
path in the 'module' directive in the imported module's go.mod file.

In general, I think some projects have switched back and forth between 
wanting to officially be known as something like 'gopkg.in/foo/bar.v1' vs. 
'github/foo/bar', which then causes mismatches if clients are out of sync, 
which might be what is going on here.

One thing you could try is something like 'go mod graph | grep 
github.com/go-resty/resty', or alternatively manually review the output of 
'go mod graph' to see if you can find someone importing the github import 
path.

(Longer discussion of the whether or not to use `module gopkg.in/foo.v1` as 
the name of your module here:
 https://github.com/russross/blackfriday/issues/491#issuecomment-425585276 
) 

--thepudds

On Wednesday, October 24, 2018 at 7:01:04 PM UTC-4, Joseph Lorenzini wrote:
>
>
> Hi all,
>
> I have a deeply nested dependency somewhere that depends on go-resty. When 
> I do a go list in my module, I see this error.
>
> go: github.com/go-resty/resty@v1.10.0: parsing go.mod: unexpected module 
> path "gopkg.in/resty.v1"
> go: error loading module requirements
>
> I checked out goresty and it does have a go.mod:
>
> https://github.com/go-resty/resty/blob/v1.10.0/go.mod
>
> The module name is gopkg.in/resty.v1
>
> So what I am guessing is that some packages have imported 
> github.com/go-resty/resty while others have imported gopkg.in/resty.v1. 
> If every package imported gopkg.in/resty.v1 then i suspect this would 
> just work since that's module name. I actually am not sure where in the 
> dependency tree this is occurring. It could be I am using package A which 
> depends on package B which requires package C and Package C is the one 
> importing github.com/go-resty/resty. 
>
> I tried a replace directive and that did not work.
>
> replace (
> github.com/go-resty/resty => gopkg.in/resty.v1 v1.10.0
> )
>
> Is there a recommended way to handle this? 
>
> Thanks,
> Joe 
>
>
>
>

-- 
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] relaxing type conversions: an "almost possible" idea with Go generics

['Axel Wagner' via golang-nuts]

On Thu, Oct 25, 2018 at 12:39 AM roger peppe  wrote:

> I understand this argument. By putting some smarts into the compiler, we
> would hope that we can see benefits not just in our generated generic code,
> but also in other code that we've already written that uses generics. This
> would be great if it wasn't very hard to do.
>

We disagree here. I still maintain that it is not harder. My intention
above was to illustrate that, by assuming we have the generics-problem
(including a heuristic to decide what to specialize) solved and then
solving the devirtualization-problem using that solution. Unfortunately,
that still seems to be unconvincing to you, though.

For example (I got a little carried away here), here's an idea of what some
> generated code using a reflect-based approach might look like:
>
> https://github.com/rogpeppe/genericdemo/blob/master/naive/naive.go
>

I'm sorry, but this seems like a strawman. This is how a realistic dynamic
approach would look like:
https://play.golang.org/p/Fbs0cpAnE43
or, if you prefer, using methods:
https://play.golang.org/p/6YsyJaVQ789
And yeah, I maintain that it's easy to devirtualize that. Especially if we
can give the compiler hints, like for example,
https://play.golang.org/p/TZNQRlvofw2

Anyway. I give up, I guess :)


>
> Imagine how smart the compiler would have to be in order to
> reverse-engineer that back to the equivalent inline code!
> You'd end up having to write patterns for the exact code that is produced
> from the compiler, with the danger that you wouldn't hit any real code at
> all (and also, coming up with sound optimisations for small variations in
> reflect code is likely to be really hard).
> I suspect you'd end up with a very slow and very fragile compiler.
>
> FWIW I went a bit further and experimented with some more potential
> representations of generic Go code so I could get an idea of the likely
> overheads. The approach of sharing implementations that use the same
> size/pointer layout seems to work ok, with about a 3 or 4 ns overhead per
> generic call on my machine (about half the speed of a direct function
> call). My experimentation is here:
> https://github.com/rogpeppe/genericdemo/blob/master/generated.go . It
> actually shouldn't be that hard to write some code to produce that kind of
> code automatically, "gofront" if you like, without updating the compiler
> wholesale. I need to stop now :)
>
>
>

-- 
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] websocket implentation in golang

[Skip Tavakkolian]

Here's a sketch:

https://gist.github.com/9nut/11052587


On Wed, Oct 24, 2018 at 4:20 AM sakthi apr  wrote:

> Hi,
>
> I'm developing web socket in golang that checks the database changes like
> new data insert.
>
> if the new record added in table user will get notified at client side.
>
> Anyone have idea plz share with me.
>
>
> Thanks
>
> --
> 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.

[go-nuts] handling unexpected module path

[Joseph Lorenzini]

Hi all,

I have a deeply nested dependency somewhere that depends on go-resty. When 
I do a go list in my module, I see this error.

go: github.com/go-resty/resty@v1.10.0: parsing go.mod: unexpected module 
path "gopkg.in/resty.v1"
go: error loading module requirements

I checked out goresty and it does have a go.mod:

https://github.com/go-resty/resty/blob/v1.10.0/go.mod

The module name is gopkg.in/resty.v1

So what I am guessing is that some packages have imported 
github.com/go-resty/resty while others have imported gopkg.in/resty.v1. If 
every package imported gopkg.in/resty.v1 then i suspect this would just 
work since that's module name. I actually am not sure where in the 
dependency tree this is occurring. It could be I am using package A which 
depends on package B which requires package C and Package C is the one 
importing github.com/go-resty/resty. 

I tried a replace directive and that did not work.

replace (
github.com/go-resty/resty => gopkg.in/resty.v1 v1.10.0
)

Is there a recommended way to handle this? 

Thanks,
Joe 



-- 
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] websocket implentation in golang

[robert engels]

You can look at github.com/robaho/go-trader 

See webserver.go and book.js

In this case, the server sends updates (market changes) to the subscribed 
clients unsolicited, but on an interval (so rapid changes on the server don’t 
flood the network).

I believe your solution would be similar - have a listener to the db that 
tracks “changes” in a map. A background go routine looks at the changes and 
sends them to websocket subscribers on an interval - grouping them for 
efficiency.

> On Oct 24, 2018, at 6:19 AM, sakthi apr  wrote:
> 
> Hi,
> 
> I'm developing web socket in golang that checks the database changes like new 
> data insert. 
> 
> if the new record added in table user will get notified at client side.
> 
> Anyone have idea plz share with me.
> 
> 
> Thanks
> 
> 
> -- 
> 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] relaxing type conversions: an "almost possible" idea with Go generics

[roger peppe]

On Sun, 21 Oct 2018 at 13:53, Axel Wagner 
wrote:

> Last addition:
>
> On Sun, Oct 21, 2018 at 2:03 PM roger peppe  wrote:
>
>> Ah, I *think* I see where you might be coming from now. You're thinking
>> that the compiler could do some kind of Go-to-Go transformation for generic
>> functions so that they looked exactly as if they'd been written using
>> interfaces, and then later transform that back into devirtualized calls.
>> Even if it were possible in general (I'm fairly sure it's not), I don't see
>> why anyone would want to take such an indirect approach when it's quite
>> possible for the compiler to compile to an intermediate format that
>> preserves all the information needed and decide how to generate the code
>> based on that.
>>
>
> The claim you made was, that generics improve performance (due to static
> dispatch and inlining etc). I contradict that claim. I believe static
> dispatch and inlining can be achieved without talking about type-parameters
> or generics at all.
>
> And to answer the question of "why would you do that" - because if you
> treat it as a generic (lol) devirtualization pass, code that *doesn't* use
> generics (but does use interfaces) also benefits from that automatically.
> For example we could actually get a powerful and properly performing
> version of image/draw without having to re-write it into a parametric API -
> the performance of existing interface-based APIs would be equivalent to
> parametric ones.
>
> It's also easier to reason about, because you are separating the
> type-checking phase from the optimization phase. Your heuristics doesn't
> need to know about the generic type info at all and you can tweak both
> individually.
>
> Essentially, the advantages of splitting it into modular pieces is the
> same reason, why functional languages desugar all language constructs into
> pure functions - if `->` is the only type constructor you need to worry
> about, it becomes much easier to talk about how different features
> interact, optimizations and whether a change to the type-system is sound.
> Also, optimizations for that basic type-constructor compound to all
> constructs.
>
> In essence, a lot of the problems discovered in the alias-discussion and
> also in the generics discussion now come down to a question of how these
> things interact with all the existing features and whether we fully
> understood the whole space of programs the language allows. Treating
> generics as essentially syntactic sugar for interfaces/reflect/… creates
> orthogonality -  at least in every compilation stage *after* type-checking.
>

I understand this argument. By putting some smarts into the compiler, we
would hope that we can see benefits not just in our generated generic code,
but also in other code that we've already written that uses generics. This
would be great if it wasn't very hard to do. For example (I got a little
carried away here), here's an idea of what some generated code using a
reflect-based approach might look like:

https://github.com/rogpeppe/genericdemo/blob/master/naive/naive.go

Imagine how smart the compiler would have to be in order to
reverse-engineer that back to the equivalent inline code!
You'd end up having to write patterns for the exact code that is produced
from the compiler, with the danger that you wouldn't hit any real code at
all (and also, coming up with sound optimisations for small variations in
reflect code is likely to be really hard).
I suspect you'd end up with a very slow and very fragile compiler.

FWIW I went a bit further and experimented with some more potential
representations of generic Go code so I could get an idea of the likely
overheads. The approach of sharing implementations that use the same
size/pointer layout seems to work ok, with about a 3 or 4 ns overhead per
generic call on my machine (about half the speed of a direct function
call). My experimentation is here:
https://github.com/rogpeppe/genericdemo/blob/master/generated.go . It
actually shouldn't be that hard to write some code to produce that kind of
code automatically, "gofront" if you like, without updating the compiler
wholesale. I need to stop now :)

-- 
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] Regarding contracts

[Burak Serdar]

On Wed, Oct 24, 2018 at 3:52 PM Andy Balholm  wrote:
>
> What I’m doing with structural contracts is basically the same as what you’re 
> doing with struct and interface types as contracts, except that (I hope) the 
> syntax is a little clearer.
>
> I added the support for operators basically to avoid having the supportsEqual 
> contract as a special case that needs to be built in. Most other operators 
> could be handled just as well with an enumerated contract, so maybe it would 
> be better to just have supportsEqual or comparable as a built-in contract.

The only problem with that, I think, is that the contract syntax is no
longer a struct or interface. I see your point though.


> I was envisioning the type switches being evaluated at compile time if the 
> compiler was producing a type-specialized version of the generic function. 
> Min(int) would probably produce exactly the same machine code as

That's a neat idea.


>
> func MinInt(a, b int) int {
> if a < b {
> return a
> }
> return b
> }
>
> Andy
>
> > On Oct 24, 2018, at 9:47 AM, Burak Serdar  wrote:
> >
> > On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm  wrote:
> >>
> >> Here’s my attempt at streamlining it, as well as adding a way to deal with 
> >> the operator/method dichotomy: 
> >> https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2
> >
> > Thanks!
> >
> > However,  I think yours is a somewhat different approach altogether.
> > The main idea I have is that existing types should be used as
> > contracts.  That means no operators in contracts.
> >
> > Also: when you list types in a contract:
> >
> > contract X {
> >  T1
> >  T2
> > }
> >
> > I defined it to mean that any type satisfying X must satisfy both T1 and T2.
> >
> > And with "like" type contract specifications (enumerated contracts)
> >
> > contract X like(int,int8,int16...)
> >
> > A type satisfying X is a derivative of any one of the types listed. So
> > it is possible to write:
> >
> > contract StrNum {
> >   like(int, int8, int16,...)
> >   interface {
> >  String() string
> >   }
> > }
> >
> > meaning StrNum must be an integer that implements String()
> >
> > The "type switch" for contracts imply that contracts are a runtime
> > construct. In my case, contracts are purely compile time.
> >
> >
> >>
> >> Andy
> >>
> >> On Oct 23, 2018, at 9:37 AM, Burak Serdar  wrote:
> >>
> >> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar  wrote:
> >>
> >>
> >> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich  wrote:
> >>
> >>
> >> * Burak Serdar  [181018 15:08]:
> >>
> >> tbh, I am not trying to avoid operator overloading, I am trying to
> >> avoid the contracts. With operator overloading, you can write:
> >>
> >> func F(a,b type T like(int,X)) {
> >>  if a >>...
> >>  }
> >> }
> >>
> >> provided X is a type that supports <.
> >>
> >>
> >> Are you trying to avoid the concept of contracts or the specific syntax
> >> proposed in the design draft?
> >>
> >>
> >>
> >> My intent was to use existing types as contracts instead of an
> >> abstract contract specification. In this scenario, a contract is a
> >> more abstract concept that an interface. Above, type T like(int,X)
> >> would mean:
> >> - func F compiles for T=int and T=X
> >> - F can be instantiated for any type derived from int or X
> >> So instead of specifying the precise type semantics required by F,
> >> you'd approximate the intent and declare that F would work for types
> >> that look like int, and X.
> >>
> >> When you apply the same idea to structs:
> >>
> >> type T like struct {a, b, int}
> >>
> >> would mean that T can be substituted by any struct containing two int
> >> fields called a and b.
> >>
> >> This idea ran into problems later on: I cannot explain simple
> >> contracts such as "type T must support ==".
> >>
> >>
> >>
> >> I typed this up in a more organized way, and it turned out to be an
> >> alternative declaration for contracts without touching the generics
> >> parts of the proposal.
> >>
> >> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
> >>
> >> --
> >> 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] relaxing type conversions: an "almost possible" idea with Go generics

[roger peppe]

On Sun, 21 Oct 2018 at 13:40, Axel Wagner 
wrote:

> On Sun, Oct 21, 2018 at 2:03 PM roger peppe  wrote:
>
>> Yes. The draft proposal says "generic functions, rather than generic
>> types, can probably be compiled using an interface-based approach. That
>> will optimize compile time, in that the package is only compiled once, but
>> there will be some run-time cost.". I don't think this is possible as
>> stated. I don't even know what it means to compile a generic type, as types
>> themselves aren't compiled - unless they're talking about compiling methods
>> on generic types, in which case I don't see how they differ from generic
>> functions.
>>
>> I do believe it's possible to avoid generating code for every possible
>> set of type parameters to a generic function. There's a continuum of
>> efficiency. At one end, we *could* generate code for each possible set of
>> type parameters (giving efficient code but binary bloat), and at the other,
>> I think it's possible to generate a function containing reflect-based code
>> that will work on all possible type parameters (*) but is comparatively
>> very slow.
>>
>
> To me, it seems that you are contradicting yourself here. To clarify: To
> me, an "interface-based approach" and "reflect-based code" essentially
> comes down to exactly the same thing: We pass run-time type information to
> the function which then unpacks that to do the actual work. Tomato Potahto
> ;)
>

The two approaches are quite different in their runtime implications. Using
reflect to make function calls is a couple of orders of magnitude slower
than calling interface methods directly.

(and FWIW "compiling a type", I believe, refers to generating a
> reflect.rtype/runtime._type at compile time and embedding it in the binary.
> So, if you have `type Foo(T) struct { x T }`, an interface-based
> compilation would just generate one run-time type of the form `type Foo
> struct { x interface{} }`, whereas a static approach would create e.g.
> `type Foo(int) struct { x int }`, `type Foo(string) struct { x string }`,
> etc)
>

> But, I guess, I'm fine to agree to disagree at that point then - if you
> think a purely run-time/reflect/interface/… approach is impossible, I can't
> argue with that :)
>

Yeah, I don't believe that's possible. Because then you couldn't have a
*Foo(byte) pointing into the middle of a slice of `struct {x byte}` values.

>

-- 
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] Go 2 Proposal Comments

[Michael Jones]

Ian, thanks for commenting. I wonder if this might be viewed as motivation
for "bigger, visible, clear" changes rather than nuanced ones.

As a ship captain, I'm trained to take "early and effective action" to
avoid problems. Not just to solve them, but to do so ina way that signals
the other boat what I'm doing. If a 3 degree heading change is enough, say,
I might do 10 for a bit just to let them see clearly that I have turned for
safety and then in a few minutes turn back closer to the 3 degree heading.
This telegraphing helps all parties. Could be the same for changes. If they
have to happen (regrettably) then maybe it is good to make them in such a
way that bon confusion between new and old was possible, or at least to the
degree that is practical.

On Wed, Oct 24, 2018 at 2:04 PM Ian Lance Taylor  wrote:

> On Wed, Oct 24, 2018 at 10:05 AM, Michael Jones 
> wrote:
> >
> > Agree on the industry dynamics observation--I remember too--but want to
> > raise another point of view on 100% backwards compatibility: when Go was
> > just a baby, in pre-1.0 days, there was exploration and new ideas. There
> was
> > also "Go Fix" to rewrite "go of the past" as "go of today." This seemed
> > genius to me in a systemic way; it meant that even bold changes could be
> > easy and 100% reliable to change. It worked.
> >
> > I'd like to see this mindset extended in two ways: to rewrite Go to new
> > idioms and to rewrite Go 1 to Go 2. On the idioms front, if the standard
> > library now appreciates read-from over write-to, then let's
> autoidiomatize
> > it. If new Go 2 error checking is introduced, let's design the rewrite
> > system and the feature in concert.
> >
> > I like this mindset and wonder if it could be sufficient to allow
> > introduction of breaking changes. This is my question here--would rewrite
> > fool assurances be enough to feel compatible in the way sought by the OP?
>
> `go fix` was cool and we should resurrect it where appropriate as we
> change the language.
>
> But I think that at this stage of the language evolution `go fix` is
> not enough to permit redefinitions of code.  We can use `go fix` to
> handle removals from the languages: cases that no longer work, that
> can be rewritten to a form that will work.  But where we have cases in
> which the same code works one way in Go 1.N and works a different way
> in Go 1.N+1, `go fix` is insufficient, because we no longer know
> reliably what meaning was intended by the author of the code.  Before
> Go 1 we could assume that everybody always meant the current version,
> whatever that was.  I don't think that is true today.
>
> Ian
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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] Regarding contracts

[Andy Balholm]

What I’m doing with structural contracts is basically the same as what you’re 
doing with struct and interface types as contracts, except that (I hope) the 
syntax is a little clearer. 

I added the support for operators basically to avoid having the supportsEqual 
contract as a special case that needs to be built in. Most other operators 
could be handled just as well with an enumerated contract, so maybe it would be 
better to just have supportsEqual or comparable as a built-in contract.

The equivalent to your StrNum example in my syntax would be:

contract num int, int8, int16…

contract StrNum {
num
String() string
}

I was envisioning the type switches being evaluated at compile time if the 
compiler was producing a type-specialized version of the generic function. 
Min(int) would probably produce exactly the same machine code as

func MinInt(a, b int) int {
if a < b {
return a
}
return b
}

Andy

> On Oct 24, 2018, at 9:47 AM, Burak Serdar  wrote:
> 
> On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm  wrote:
>> 
>> Here’s my attempt at streamlining it, as well as adding a way to deal with 
>> the operator/method dichotomy: 
>> https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2
> 
> Thanks!
> 
> However,  I think yours is a somewhat different approach altogether.
> The main idea I have is that existing types should be used as
> contracts.  That means no operators in contracts.
> 
> Also: when you list types in a contract:
> 
> contract X {
>  T1
>  T2
> }
> 
> I defined it to mean that any type satisfying X must satisfy both T1 and T2.
> 
> And with "like" type contract specifications (enumerated contracts)
> 
> contract X like(int,int8,int16...)
> 
> A type satisfying X is a derivative of any one of the types listed. So
> it is possible to write:
> 
> contract StrNum {
>   like(int, int8, int16,...)
>   interface {
>  String() string
>   }
> }
> 
> meaning StrNum must be an integer that implements String()
> 
> The "type switch" for contracts imply that contracts are a runtime
> construct. In my case, contracts are purely compile time.
> 
> 
>> 
>> Andy
>> 
>> On Oct 23, 2018, at 9:37 AM, Burak Serdar  wrote:
>> 
>> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar  wrote:
>> 
>> 
>> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich  wrote:
>> 
>> 
>> * Burak Serdar  [181018 15:08]:
>> 
>> tbh, I am not trying to avoid operator overloading, I am trying to
>> avoid the contracts. With operator overloading, you can write:
>> 
>> func F(a,b type T like(int,X)) {
>>  if a>...
>>  }
>> }
>> 
>> provided X is a type that supports <.
>> 
>> 
>> Are you trying to avoid the concept of contracts or the specific syntax
>> proposed in the design draft?
>> 
>> 
>> 
>> My intent was to use existing types as contracts instead of an
>> abstract contract specification. In this scenario, a contract is a
>> more abstract concept that an interface. Above, type T like(int,X)
>> would mean:
>> - func F compiles for T=int and T=X
>> - F can be instantiated for any type derived from int or X
>> So instead of specifying the precise type semantics required by F,
>> you'd approximate the intent and declare that F would work for types
>> that look like int, and X.
>> 
>> When you apply the same idea to structs:
>> 
>> type T like struct {a, b, int}
>> 
>> would mean that T can be substituted by any struct containing two int
>> fields called a and b.
>> 
>> This idea ran into problems later on: I cannot explain simple
>> contracts such as "type T must support ==".
>> 
>> 
>> 
>> I typed this up in a more organized way, and it turned out to be an
>> alternative declaration for contracts without touching the generics
>> parts of the proposal.
>> 
>> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
>> 
>> --
>> 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] Having trouble installing golint

['kalekold' via golang-nuts]

It must have been a configuration issue on the remote server because it all 
works fine now.

On Wednesday, 17 October 2018 22:05:48 UTC+1, Sam Whited wrote:
>
> 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 the package path. When you run go get 
> golang.org/x/lint/golint it will look up the repo, discover that it lives 
> at GitHub, clone it, and build it. 
>
> If you don't specify another package import path and you host your source 
> on GitHub the github.com url is the default one, which may be why you are 
> confused. However, golint specifies a custom import path (
> golang.org/x/lint/golint) so you need to use that. 
>
> —Sam 
>
> On Wed, Oct 17, 2018, at 14:48, 'kalekold' via golang-nuts wrote: 
> > 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{Prefix: 
> > "golang.org/x/lint", VCS:"git", 
> > RepoRoot:"https://go.googlesource.com/lint"} 
> > at https://golang.org/x/lint/golint?go-get=1 
> > get "golang.org/x/lint/golint": verifying non-authoritative meta tag 
> > Fetching https://golang.org/x/lint?go-get=1 
> > Parsing meta tags from https://golang.org/x/lint?go-get=1 (status code 
> > 200) 
> > golang.org/x/lint (download) 
> > Fetching https://golang.org/x/lint?go-get=1 
> > Parsing meta tags from https://golang.org/x/lint?go-get=1 (status code 
> > 200) 
> > get "golang.org/x/lint": found meta tag get.metaImport{Prefix: 
> > "golang.org/x/lint", VCS:"git", 
> > RepoRoot:"https://go.googlesource.com/lint"} 
> > at https://golang.org/x/lint?go-get=1 
> > Fetching https://golang.org/x/tools/go/ast/astutil?go-get=1 
> > Parsing meta tags from 
> > https://golang.org/x/tools/go/ast/astutil?go-get=1 
> > (status code 200) 
> > get "golang.org/x/tools/go/ast/astutil": found meta tag get.metaImport{ 
> > Prefix:"golang.org/x/tools", VCS:"git", RepoRoot: 
> > "https://go.googlesource.com/tools"} at https: 
> > //golang.org/x/tools/go/ast/astutil?go-get=1 
> > get "golang.org/x/tools/go/ast/astutil": verifying non-authoritative 
> > meta 
> > tag 
> > Fetching https://golang.org/x/tools?go-get=1 
> > Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 
> > 200) 
> > golang.org/x/tools (download) 
> > Fetching https://golang.org/x/tools/go/gcexportdata?go-get=1 
> > Parsing meta tags from 
> > https://golang.org/x/tools/go/gcexportdata?go-get=1 
> > (status code 200) 
> > get "golang.org/x/tools/go/gcexportdata": found meta tag 
> get.metaImport{ 
> > Prefix:"golang.org/x/tools", VCS:"git", RepoRoot: 
> > "https://go.googlesource.com/tools"} at https: 
> > //golang.org/x/tools/go/gcexportdata?go-get=1 
> > get "golang.org/x/tools/go/gcexportdata": verifying non-authoritative 
> > meta 
> > tag 
> > Fetching https://golang.org/x/tools/go/internal/gcimporter?go-get=1 
> > Parsing meta tags from 
> > https://golang.org/x/tools/go/internal/gcimporter?go-get=1 
> > (status code 200) 
> > get "golang.org/x/tools/go/internal/gcimporter": found meta tag get. 
> > metaImport{Prefix:"golang.org/x/tools", VCS:"git", RepoRoot: 
> > "https://go.googlesource.com/tools"} at https: 
> > //golang.org/x/tools/go/internal/gcimporter?go-get=1 
> > get "golang.org/x/tools/go/internal/gcimporter": verifying non- 
> > authoritative 
> > meta tag 
> > 
> > $ go get -u -v github.com/golang/lint/golint 
> > github.com/golang/lint (download) 
> > package github.com/golang/lint/golint: code in directory /media/Data/ 
> > Projects/Go/src/github.com/golang/lint/golint expects import 
> > "golang.org/x/lint/golint" 
> > 
> > 
> > On Wednesday, 17 October 2018 17:53:50 UTC+1, Sam Whited wrote: 
> > > 
> > > 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.wi...@victoriaplumb.com 
>  
> > > wrote: 
> > > > 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/golint" 
> > > > 
> > > > -- 
> > > > 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 . 

Re: [go-nuts] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[Liam]

I don't think we'll see check in the next draft. A LOT of the feedback[1] 
suggests various ways to invoke a named handler. But these are awkward:
  check(name) f(a)
  check(name, f(a))
  f(a) check name

I hope check will be supplanted[2] by *symbol handler_name*, e.g.
  ?name = f(a); x(f?name(a))
  #name = f(a); x(f#name(a))
  @name = f(a); x(f@name(a))

[1] https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback
[2] https://gist.github.com/networkimprov/961c9caa2631ad3b95413f7d44a2c98a


On Wednesday, October 24, 2018 at 8:38:35 AM UTC-7, alan...@gmail.com wrote:
>
> Hmm, interesting idea!
>
> Presumably, that would still work if 'check' were declared as a local 
> variable within the same function *after* all the error handling stuff, 
> as the compiler would detect it on first pass.
>
> I wondered myself about having some sort of pragma or pseudo-import (say: 
> import . "E") at top level within the package to turn the new error 
> handling on but as that would be a new feature in itself perhaps it's not 
> such a good idea.
>
> Alan
>
> On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Wed, Oct 24, 2018 at 3:49 AM, alanfo  wrote: 
>> > 
>> > I quite like the draft error handling design and haven't (so far) 
>> suggested 
>> > that any changes be made. 
>> > 
>> > However, one aspect I don't like is 'check' and 'handle' having to be 
>> > keywords which means that the design is not Go 1 compatible. Also, 
>> whilst I 
>> > agree that these words are probably the best ones for the job (and I 
>> would 
>> > hate to see them replaced by obscure symbols) it seems a pity that such 
>> > commonly used words will no longer be available as ordinary 
>> identifiers. 
>> > 
>> > So all I'm asking here is whether - if the design were adopted as it 
>> stands 
>> > - they could be 'contextual' rather than 'full' keywords? I couldn't 
>> find 
>> > any mention of this in the draft papers but apologize in advance if 
>> it's 
>> > been addressed and I've missed it. 
>> > 
>> > As far as this thread is concerned, I'm only interested in this 
>> question and 
>> > not what people think of the design generally. 
>> > 
>> > It seems to me that they probably could be 'contextual' keywords i.e. 
>> they 
>> > could still be used as ordinary identifiers in the same package or even 
>> > within the same function (though the latter wouldn't be a great idea 
>> from a 
>> > readability perspective). 
>> > 
>> > Considering first 'handle' which must be the first word in a line and 
>> then 
>> > be followed by an identifier. It cannot be any of the following: 
>> > 
>> > 1. A function call because its not followed by (. 
>> > 
>> > 2. An assignment because it's not followed by an =, :=  or , token. 
>> > 
>> > 3. An indexation expression because it's not followed by [. 
>> > 
>> > 4. A struct literal because it's not (directly) followed by {. 
>> > 
>> > 5. Any other expression because it's not followed by an operator. 
>> > 
>> > So can anyone think of anything else it could be? 
>> > 
>> > However, 'check' is more awkward because it's followed by an expression 
>> (not 
>> > an identifier) and need not be the first word in the line. If the 
>> expression 
>> > were bracketed or preceded by a unary operator then there would be a 
>> > potential ambiguity with #1 or #5 respectively. 
>> > 
>> > So would it suffice for the compiler to try and interpret 'check' in 
>> these 
>> > situations as a 'normal' identifier and issue an error if it couldn't 
>> but 
>> > otherwise to interpret it as a error handling keyword? 
>> > 
>> > The error would of course be easy enough to fix but, even if there are 
>> no 
>> > other ambiguities, would it just be too confusing and should we simply 
>> > accept that 'check' has to be a 'full' keyword as the design stands? 
>>
>> I think that if a package does define `check` as a local function, 
>> then making contextual choices about whether `check` in an expression 
>> refers to the function or to the error checking behavior can only be 
>> confusing. 
>>
>> One approach that could perhaps work--and I'm not at all endorsing 
>> this, just pointing it out--is that if a package defines `check` as a 
>> local name of any sort, the compiler could simply disable the error 
>> checking behavior of `check`.  That is, `check` would only be a 
>> keyword if there were no local definition of `check`. 
>>
>> 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] Go 2 Proposal Comments

[Ian Lance Taylor]

On Wed, Oct 24, 2018 at 10:05 AM, Michael Jones  wrote:
>
> Agree on the industry dynamics observation--I remember too--but want to
> raise another point of view on 100% backwards compatibility: when Go was
> just a baby, in pre-1.0 days, there was exploration and new ideas. There was
> also "Go Fix" to rewrite "go of the past" as "go of today." This seemed
> genius to me in a systemic way; it meant that even bold changes could be
> easy and 100% reliable to change. It worked.
>
> I'd like to see this mindset extended in two ways: to rewrite Go to new
> idioms and to rewrite Go 1 to Go 2. On the idioms front, if the standard
> library now appreciates read-from over write-to, then let's autoidiomatize
> it. If new Go 2 error checking is introduced, let's design the rewrite
> system and the feature in concert.
>
> I like this mindset and wonder if it could be sufficient to allow
> introduction of breaking changes. This is my question here--would rewrite
> fool assurances be enough to feel compatible in the way sought by the OP?

`go fix` was cool and we should resurrect it where appropriate as we
change the language.

But I think that at this stage of the language evolution `go fix` is
not enough to permit redefinitions of code.  We can use `go fix` to
handle removals from the languages: cases that no longer work, that
can be rewritten to a form that will work.  But where we have cases in
which the same code works one way in Go 1.N and works a different way
in Go 1.N+1, `go fix` is insufficient, because we no longer know
reliably what meaning was intended by the author of the code.  Before
Go 1 we could assume that everybody always meant the current version,
whatever that was.  I don't think that is true today.

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] New keywords and backwards compatibility

[robert engels]

I like the idea. Simple. I think the go documentation needs to have similar 
@Since annotations like Java. I would also strongly suggest no breaking APIs - 
ever...

> On Oct 24, 2018, at 2:14 PM, Ian Denhardt  wrote:
> 
> Hey all,
> 
> Today I've seen a lot of messages re: concerns about adding new keywords
> and breaking backwards compatibility. People have floated a couple
> approaches to avoiding breakage. But I feel like all of them that I've
> seen so far will make code confusing. I'd like to propose an
> alternative, which doesn't perfectly preserve backwards compatibility,
> but:
> 
> 1. Allows go 1 and go 2 to be mixed, provided they're in different
> source files, and
> 2. Has a clear and trivial upgrade path that can be automated, and
> can also be done incrementally in a non-disruptive fashion.
> 
> Here's the idea:  the first Go release that includes the new
> keywords introduces a new specially-recognized comment, something
> like
> 
> // go:keywords 2
> 
> This comment can be used to control which version of the language
> source file is interpreted as. So to opt into the new features, a source
> can add that comment to a source file.
> 
> At the top. Other source files will continue to treat the new keywords
> as identifiers.
> 
> Note that since the keywords are all lower-case, this won't cause
> problems with interoperability at the API level; any Go 1 package
> that currently uses one of these keywords as an identifier only
> does so privately, so Go 2 code can still import those packages and
> not run into problems with not being able to specify a name in the
> package.
> 
> When we finally release "Go 2.0," the only backwards-incompatible
> change we make is that that the default is to use the new keywords, and
> we add another specially-recognized comment:
> 
> // go:keywords 1
> 
> which causes the keywords to be treated as identifiers, as in Go 1.
> 
> We could also add a flag to go build, so that  users wanting to build an
> old Go 1 codebase can just run:
> 
> go build -go1
> 
> And everything will just work. Updating to the new version is easy and
> can be done incrementally: just rename any variables that collide with
> the keyword.
> 
> Thoughts?
> 
> -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.

-- 
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] New keywords and backwards compatibility

[Ian Lance Taylor]

On Wed, Oct 24, 2018 at 12:14 PM, Ian Denhardt  wrote:
>
> Thoughts?

Please read https://golang.org/issue/28221 and the background doc
linked there.  I suggest that you comment on that issue, which is
exactly about the topics you raise here.  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.

[go-nuts] Re: New keywords and backwards compatibility

[Liam]

I suggested a //go:lang directive to select non-backwards-compatible 
features on the issue below, but it was rejected.

https://github.com/golang/go/issues/28221

Note also the semver suggestion that each new version which provides 
non-backwards-compatible features should get a new major version, meaning a 
Go 3.x series shortly after Go 2.x.

On Wednesday, October 24, 2018 at 12:16:15 PM UTC-7, Ian Denhardt wrote:
>
> Hey all, 
>
> Today I've seen a lot of messages re: concerns about adding new keywords 
> and breaking backwards compatibility. People have floated a couple 
> approaches to avoiding breakage. But I feel like all of them that I've 
> seen so far will make code confusing. I'd like to propose an 
> alternative, which doesn't perfectly preserve backwards compatibility, 
> but: 
>
> 1. Allows go 1 and go 2 to be mixed, provided they're in different 
> source files, and 
> 2. Has a clear and trivial upgrade path that can be automated, and 
> can also be done incrementally in a non-disruptive fashion. 
>
> Here's the idea:  the first Go release that includes the new 
> keywords introduces a new specially-recognized comment, something 
> like 
>
> // go:keywords 2 
>
> This comment can be used to control which version of the language 
> source file is interpreted as. So to opt into the new features, a source 
> can add that comment to a source file. 
>
> At the top. Other source files will continue to treat the new keywords 
> as identifiers. 
>
> Note that since the keywords are all lower-case, this won't cause 
> problems with interoperability at the API level; any Go 1 package 
> that currently uses one of these keywords as an identifier only 
> does so privately, so Go 2 code can still import those packages and 
> not run into problems with not being able to specify a name in the 
> package. 
>
> When we finally release "Go 2.0," the only backwards-incompatible 
> change we make is that that the default is to use the new keywords, and 
> we add another specially-recognized comment: 
>
> // go:keywords 1 
>
> which causes the keywords to be treated as identifiers, as in Go 1. 
>
> We could also add a flag to go build, so that  users wanting to build an 
> old Go 1 codebase can just run: 
>
> go build -go1 
>
> And everything will just work. Updating to the new version is easy and 
> can be done incrementally: just rename any variables that collide with 
> the keyword. 
>
> Thoughts? 
>
> -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.

[go-nuts] New keywords and backwards compatibility

[Ian Denhardt]

Hey all,

Today I've seen a lot of messages re: concerns about adding new keywords
and breaking backwards compatibility. People have floated a couple
approaches to avoiding breakage. But I feel like all of them that I've
seen so far will make code confusing. I'd like to propose an
alternative, which doesn't perfectly preserve backwards compatibility,
but:

1. Allows go 1 and go 2 to be mixed, provided they're in different
source files, and
2. Has a clear and trivial upgrade path that can be automated, and
can also be done incrementally in a non-disruptive fashion.

Here's the idea:  the first Go release that includes the new
keywords introduces a new specially-recognized comment, something
like

// go:keywords 2

This comment can be used to control which version of the language
source file is interpreted as. So to opt into the new features, a source
can add that comment to a source file.

At the top. Other source files will continue to treat the new keywords
as identifiers.

Note that since the keywords are all lower-case, this won't cause
problems with interoperability at the API level; any Go 1 package
that currently uses one of these keywords as an identifier only
does so privately, so Go 2 code can still import those packages and
not run into problems with not being able to specify a name in the
package.

When we finally release "Go 2.0," the only backwards-incompatible
change we make is that that the default is to use the new keywords, and
we add another specially-recognized comment:

// go:keywords 1

which causes the keywords to be treated as identifiers, as in Go 1.

We could also add a flag to go build, so that  users wanting to build an
old Go 1 codebase can just run:

go build -go1

And everything will just work. Updating to the new version is easy and
can be done incrementally: just rename any variables that collide with
the keyword.

Thoughts?

-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.

[go-nuts] Re: Go 2 Proposal Comments

[alanfo]

I didn't know that Ian had written this proposal so thanks for linking to 
it.

Although I haven't had time to read it in detail, I certainly agree with 
the tenor of what he's saying.

I know more about C# than Java and the language team there have always been 
paranoid about not breaking compatibility with previous versions. Although 
lots of new keywords have been introduced since version 1.0, I think I'm 
right in saying that all of them have been 'contextual' and that no 
features have been removed from the language at all!

Given that Go is quite a small language (much smaller than C#), I think 
that removing features from the language is simply not worth the hassle 
unless they are incompatible with new features or are downright dangerous.

Removing the integer to string conversion would break a lot of code (I use 
it quite a lot myself to convert a byte or a rune to a string) and so I'd 
be disappointed if that were done. Sure it can be mildly confusing but 
that's all.

I've also seen it suggested that complex numbers should be removed from the 
language and, whilst they may only be used by a minority of Go programmers, 
they do no harm, work just fine and are in C99 as well. If you moved them 
to the standard library then (unless operator overloading is introduced) 
they'd be far harder to use.

Alan

On Wednesday, October 24, 2018 at 4:59:34 PM UTC+1, robert engels wrote:
>
> I'd like to offer a few comments on Ian's 
> https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md
>
> Since the author admits the least amount of experience with Java, maybe my 
> facts, and many opinions, might offer some insight.
>
> If you head back to the genesis time of Java, there was a dominant tech 
> company that produced the dominant OS and associated development tools. It 
> was a “their way of or the highway” scenario. Almost like clockwork, every 
> OS change was not backwards compatible, at least from the point of, if you 
> wanted to use the new feature in the latest OS, you needed to use new APIs 
> for even the “old stuff”. So development teams and businesses were in this 
> continuous cycle of rewriting the same code for a new API, every few years, 
> all without delivering any new value. Couple this with, you had to be 
> “current” in order to get “support”, and it’s easy to see the strangle hold 
> they had on an industry.
>
> When Java came along there was a heavy sigh of relief by ISVs that 
> understood write-once, and it will continue to work even as mega company 
> released new OS versions and APIs - the burden was on the JDK/JRE 
> implementation to make sure it worked - not the business. The write-once 
> run “anywhere” was icing on the cake - it opened doors to some markets very 
> cheaply.
>
> To this day, you can take a “binary” written for Java 1.0 and it will run 
> under the latest JRE. You can compile Java 1.0 source code with the latest 
> compiler. This is an amazing accomplishment that can’t be understated.
>
> Over the years, with the benefit of hindsight, many of the Java APIs were 
> deemed insufficient, or better designs emerged, and they were deprecated, 
> with the warning, "may be removed in a future release”.
>
> To my knowledge a deprecated API in the stdlib has never been removed. The 
> “deprecation” label is more of a “hey, there are better ways of doing this, 
> and you should use them…”.
>
> I think Go would be best served by ensuring that any future release is 
> 100% backwards compatible with previous releases. This is the number one 
> aspect of Java (IMO) that lead to its success - it drastically reduced the 
> churn/expense of delivering software. Businesses like this…. Developers 
> like this...
>
> In the end, if Go can deliver on the cross platform (some of the OS 
> specific APIs were a bad choice in some ways IMO, although it is not a deal 
> breaker), and the 100% backwards compatibility, I don’t see any reason why 
> Go couldn’t become as ubiquitous as Java.
>
> I believe in the end there will two languages left standing. Java for 
> enterprise apps, and Go for system tools, services, and even OS building. 
> It is nearly 2020 - manual memory management is done, dynamic languages are 
> done...
>
> Even in the browser, I think Google has figured out what Java folks knew 
> 20 years ago, JS is a mess, and having a VM in the browser is the way to 
> go. WebAssembly is the poor mans Java applet. We’re coming full circle…
>
> So to sum up, 100% backwards compatibility is a key to Go’s dominance 
> moving forward, again IMO )
>
>
>
>
>

-- 
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] Using default in select causes a deadlock

[Burak Serdar]

On Wed, Oct 24, 2018 at 11:17 AM Sathish VJ  wrote:
>
> Thank you.  Would you have an explanation for why it works so differently 
> from using default?

The codepath that causes the deadlock is :
 - main reads from c
 - f() runs select, quit is not writable, so selects default, which
starts waiting on c
 - main waits on quit



>
> On Wednesday, 24 October 2018 22:44:26 UTC+5:30, Burak Serdar wrote:
>>
>> You can do this instead:
>>
>> https://play.golang.org/p/avMIyYlwxbF
>> On Wed, Oct 24, 2018 at 11:05 AM Sathish VJ  wrote:
>> >
>> > This is a program where the receiver is asking the sender to close after 
>> > receiving 1 value.  Using default for the sending (line 34) causes the 
>> > code to deadlock while even a timeout of a nanosecond causes it to be ok.
>> > I don't want to time the sending though.  Is there a better option to 
>> > sequence this code?
>> > Is using default not an option here at all?
>> >
>> > https://play.golang.org/p/30sI9RYJ1Ed
>> >
>> > package main
>> >
>> > import "fmt"
>> > //import "time"
>> >
>> > var c = make(chan string)
>> > var quit = make(chan bool)
>> >
>> > func main() {
>> > go fn()
>> >
>> > for {
>> > select {
>> > case msg, ok := <-c:
>> > if !ok {
>> > c = nil
>> > return
>> > } else {
>> > fmt.Println("received: ", msg)
>> > quit <- true
>> > }
>> > }
>> > }
>> > }
>> >
>> > func fn() {
>> > for {
>> > select {
>> > case <-quit:
>> > fmt.Println("closin chan c")
>> > close(c)
>> > return
>> > //case <-time.After(time.Nanosecond):  // this is ok
>> > default:   // using default causes deadlock
>> > c <- "Image"
>> > }
>> > }
>> > }
>> >
>> >
>> >
>> > received:  Image
>> > fatal error: all goroutines are asleep - deadlock!
>> >
>> > goroutine 1 [chan send]:
>> > main.main()
>> > /tmp/sandbox497027958/main.go:20 +0x100
>> >
>> > goroutine 5 [chan send]:
>> > main.fn()
>> > /tmp/sandbox497027958/main.go:35 +0x40
>> > created by main.main
>> > /tmp/sandbox497027958/main.go:10 +0x40
>> >
>> >
>> >
>> > --
>> > 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.

-- 
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] Using default in select causes a deadlock

[Sathish VJ]

Thank you.  Would you have an explanation for why it works so differently 
from using default?

On Wednesday, 24 October 2018 22:44:26 UTC+5:30, Burak Serdar wrote:
>
> You can do this instead: 
>
> https://play.golang.org/p/avMIyYlwxbF 
> On Wed, Oct 24, 2018 at 11:05 AM Sathish VJ  > wrote: 
> > 
> > This is a program where the receiver is asking the sender to close after 
> receiving 1 value.  Using default for the sending (line 34) causes the code 
> to deadlock while even a timeout of a nanosecond causes it to be ok. 
> > I don't want to time the sending though.  Is there a better option to 
> sequence this code? 
> > Is using default not an option here at all? 
> > 
> > https://play.golang.org/p/30sI9RYJ1Ed 
> > 
> > package main 
> > 
> > import "fmt" 
> > //import "time" 
> > 
> > var c = make(chan string) 
> > var quit = make(chan bool) 
> > 
> > func main() { 
> > go fn() 
> > 
> > for { 
> > select { 
> > case msg, ok := <-c: 
> > if !ok { 
> > c = nil 
> > return 
> > } else { 
> > fmt.Println("received: ", msg) 
> > quit <- true 
> > } 
> > } 
> > } 
> > } 
> > 
> > func fn() { 
> > for { 
> > select { 
> > case <-quit: 
> > fmt.Println("closin chan c") 
> > close(c) 
> > return 
> > //case <-time.After(time.Nanosecond):  // this is ok 
> > default:   // using default causes deadlock 
> > c <- "Image" 
> > } 
> > } 
> > } 
> > 
> > 
> > 
> > received:  Image 
> > fatal error: all goroutines are asleep - deadlock! 
> > 
> > goroutine 1 [chan send]: 
> > main.main() 
> > /tmp/sandbox497027958/main.go:20 +0x100 
> > 
> > goroutine 5 [chan send]: 
> > main.fn() 
> > /tmp/sandbox497027958/main.go:35 +0x40 
> > created by main.main 
> > /tmp/sandbox497027958/main.go:10 +0x40 
> > 
> > 
> > 
> > -- 
> > 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] Using default in select causes a deadlock

[Burak Serdar]

You can do this instead:

https://play.golang.org/p/avMIyYlwxbF
On Wed, Oct 24, 2018 at 11:05 AM Sathish VJ  wrote:
>
> This is a program where the receiver is asking the sender to close after 
> receiving 1 value.  Using default for the sending (line 34) causes the code 
> to deadlock while even a timeout of a nanosecond causes it to be ok.
> I don't want to time the sending though.  Is there a better option to 
> sequence this code?
> Is using default not an option here at all?
>
> https://play.golang.org/p/30sI9RYJ1Ed
>
> package main
>
> import "fmt"
> //import "time"
>
> var c = make(chan string)
> var quit = make(chan bool)
>
> func main() {
> go fn()
>
> for {
> select {
> case msg, ok := <-c:
> if !ok {
> c = nil
> return
> } else {
> fmt.Println("received: ", msg)
> quit <- true
> }
> }
> }
> }
>
> func fn() {
> for {
> select {
> case <-quit:
> fmt.Println("closin chan c")
> close(c)
> return
> //case <-time.After(time.Nanosecond):  // this is ok
> default:   // using default causes deadlock
> c <- "Image"
> }
> }
> }
>
>
>
> received:  Image
> fatal error: all goroutines are asleep - deadlock!
>
> goroutine 1 [chan send]:
> main.main()
> /tmp/sandbox497027958/main.go:20 +0x100
>
> goroutine 5 [chan send]:
> main.fn()
> /tmp/sandbox497027958/main.go:35 +0x40
> created by main.main
> /tmp/sandbox497027958/main.go:10 +0x40
>
>
>
> --
> 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.

[go-nuts] Using default in select causes a deadlock

[Sathish VJ]

This is a program where the receiver is asking the sender to close after 
receiving 1 value.  Using default for the sending (line 34) causes the code 
to deadlock while even a timeout of a nanosecond causes it to be ok.  
I don't want to time the sending though.  Is there a better option to 
sequence this code?
Is using default not an option here at all?

https://play.golang.org/p/30sI9RYJ1Ed

package main

import "fmt"
//import "time"

var c = make(chan string)
var quit = make(chan bool)

func main() {
go fn()

for {
select {
case msg, ok := <-c:
if !ok {
c = nil
return
} else {
fmt.Println("received: ", msg)
quit <- true
}
}
}
}

func fn() {
for {
select {
case <-quit:
fmt.Println("closin chan c")
close(c)
return
//case <-time.After(time.Nanosecond):  // this is ok
default:   // using default causes deadlock
c <- "Image"
}
}
}



received:  Imagefatal error: all goroutines are asleep - deadlock!

goroutine 1 [chan send]:
main.main()
/tmp/sandbox497027958/main.go:20 +0x100

goroutine 5 [chan send]:
main.fn()
/tmp/sandbox497027958/main.go:35 +0x40
created by main.main
/tmp/sandbox497027958/main.go:10 +0x40



-- 
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] Go 2 Proposal Comments

[Michael Jones]

Agree on the industry dynamics observation--I remember too--but want to
raise another point of view on 100% backwards compatibility: when Go was
just a baby, in pre-1.0 days, there was exploration and new ideas. There
was also "Go Fix" to rewrite "go of the past" as "go of today." This seemed
genius to me in a systemic way; it meant that even bold changes could be
easy and 100% reliable to change. It worked.

I'd like to see this mindset extended in two ways: to rewrite Go to new
idioms and to rewrite Go 1 to Go 2. On the idioms front, if the standard
library now appreciates read-from over write-to, then let's autoidiomatize
it. If new Go 2 error checking is introduced, let's design the rewrite
system and the feature in concert.

I like this mindset and wonder if it could be sufficient to allow
introduction of breaking changes. This is my question here--would rewrite
fool assurances be enough to feel compatible in the way sought by the OP?

Michael

On Wed, Oct 24, 2018 at 9:40 AM robert engels  wrote:

> Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t
> apply to Go.
>
> As I pointed out in an earlier email, I think the future of Go is that the
> shipped binary will be runtime linked against the standard library and
> runtime. This is by far the easier way to deliver security patches. You
> will probably pay a performance hit due to lack of inlining, but for a
> large class of applications this would be a easy trade-off to make to
> simplify security handling.
>
> > On Oct 24, 2018, at 11:26 AM, Burak Serdar  wrote:
> >
> > On Wed, Oct 24, 2018 at 10:21 AM robert engels 
> wrote:
> >>
> >> I think enum was a reserved word from the beginning - like goto - if
> not it was VERY early on when it was added. Still, the code would of run on
> the latest JVM, it might not of compiled. Outside of that possible case, I
> can’t think of another keyword that has been added - maybe the recent
> addition of ‘var’ - but don’t get me started on what it happening with Java
> now - I think there are very different forces at work than the founding
> principles.
> >
> > You might be right on the history of "enum", but the point is that any
> > time you add a keyword, something breaks.
> >
> > The point that old code can run on new JVM is inapplicable in my
> > opinion when comparing Java and Go.
> >
> > Also, it may not always be a good thing to preserve backward
> > compatibility. Opinions differ on this, but I think generics in Java
> > is a convoluted piece of mess.
> >
> >>
> >> On Oct 24, 2018, at 11:12 AM, Burak Serdar  wrote:
> >>
> >> On Wed, Oct 24, 2018 at 9:59 AM robert engels 
> wrote:
> >>
> >>
> >> To this day, you can take a “binary” written for Java 1.0 and it will
> run under the latest JRE. You can compile Java 1.0 source code with the
> latest compiler. This is an amazing accomplishment that can’t be
> understated.
> >>
> >>
> >> That is not exactly true, is it? Any time a new keyword is added to
> >> the language something breaks. They added "enum" at some point, and
> >> all programs using enum as an identifier stopped compiling.
> >>
> >>
> >> Over the years, with the benefit of hindsight, many of the Java APIs
> were deemed insufficient, or better designs emerged, and they were
> deprecated, with the warning, "may be removed in a future release”.
> >>
> >> To my knowledge a deprecated API in the stdlib has never been removed.
> The “deprecation” label is more of a “hey, there are better ways of doing
> this, and you should use them…”.
> >>
> >> I think Go would be best served by ensuring that any future release is
> 100% backwards compatible with previous releases. This is the number one
> aspect of Java (IMO) that lead to its success - it drastically reduced the
> churn/expense of delivering software. Businesses like this…. Developers
> like this...
> >>
> >> In the end, if Go can deliver on the cross platform (some of the OS
> specific APIs were a bad choice in some ways IMO, although it is not a deal
> breaker), and the 100% backwards compatibility, I don’t see any reason why
> Go couldn’t become as ubiquitous as Java.
> >>
> >> I believe in the end there will two languages left standing. Java for
> enterprise apps, and Go for system tools, services, and even OS building.
> It is nearly 2020 - manual memory management is done, dynamic languages are
> done...
> >>
> >> Even in the browser, I think Google has figured out what Java folks
> knew 20 years ago, JS is a mess, and having a VM in the browser is the way
> to go. WebAssembly is the poor mans Java applet. We’re coming full circle…
> >>
> >> So to sum up, 100% backwards compatibility is a key to Go’s dominance
> moving forward, again IMO )
> >>
> >>
> >>
> >>
> >> --
> >> 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, 

Re: [go-nuts] Go 2 Proposal Comments

[robert engels]

Btw, for those that are interested, enum was added in Java5, the same time they 
added generics. It constituted the 3rd revision to the JLS.

> On Oct 24, 2018, at 11:39 AM, robert engels  wrote:
> 
> Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t apply 
> to Go.
> 
> As I pointed out in an earlier email, I think the future of Go is that the 
> shipped binary will be runtime linked against the standard library and 
> runtime. This is by far the easier way to deliver security patches. You will 
> probably pay a performance hit due to lack of inlining, but for a large class 
> of applications this would be a easy trade-off to make to simplify security 
> handling.
> 
>> On Oct 24, 2018, at 11:26 AM, Burak Serdar  wrote:
>> 
>> On Wed, Oct 24, 2018 at 10:21 AM robert engels  wrote:
>>> 
>>> I think enum was a reserved word from the beginning - like goto - if not it 
>>> was VERY early on when it was added. Still, the code would of run on the 
>>> latest JVM, it might not of compiled. Outside of that possible case, I 
>>> can’t think of another keyword that has been added - maybe the recent 
>>> addition of ‘var’ - but don’t get me started on what it happening with Java 
>>> now - I think there are very different forces at work than the founding 
>>> principles.
>> 
>> You might be right on the history of "enum", but the point is that any
>> time you add a keyword, something breaks.
>> 
>> The point that old code can run on new JVM is inapplicable in my
>> opinion when comparing Java and Go.
>> 
>> Also, it may not always be a good thing to preserve backward
>> compatibility. Opinions differ on this, but I think generics in Java
>> is a convoluted piece of mess.
>> 
>>> 
>>> On Oct 24, 2018, at 11:12 AM, Burak Serdar  wrote:
>>> 
>>> On Wed, Oct 24, 2018 at 9:59 AM robert engels  wrote:
>>> 
>>> 
>>> To this day, you can take a “binary” written for Java 1.0 and it will run 
>>> under the latest JRE. You can compile Java 1.0 source code with the latest 
>>> compiler. This is an amazing accomplishment that can’t be understated.
>>> 
>>> 
>>> That is not exactly true, is it? Any time a new keyword is added to
>>> the language something breaks. They added "enum" at some point, and
>>> all programs using enum as an identifier stopped compiling.
>>> 
>>> 
>>> Over the years, with the benefit of hindsight, many of the Java APIs were 
>>> deemed insufficient, or better designs emerged, and they were deprecated, 
>>> with the warning, "may be removed in a future release”.
>>> 
>>> To my knowledge a deprecated API in the stdlib has never been removed. The 
>>> “deprecation” label is more of a “hey, there are better ways of doing this, 
>>> and you should use them…”.
>>> 
>>> I think Go would be best served by ensuring that any future release is 100% 
>>> backwards compatible with previous releases. This is the number one aspect 
>>> of Java (IMO) that lead to its success - it drastically reduced the 
>>> churn/expense of delivering software. Businesses like this…. Developers 
>>> like this...
>>> 
>>> In the end, if Go can deliver on the cross platform (some of the OS 
>>> specific APIs were a bad choice in some ways IMO, although it is not a deal 
>>> breaker), and the 100% backwards compatibility, I don’t see any reason why 
>>> Go couldn’t become as ubiquitous as Java.
>>> 
>>> I believe in the end there will two languages left standing. Java for 
>>> enterprise apps, and Go for system tools, services, and even OS building. 
>>> It is nearly 2020 - manual memory management is done, dynamic languages are 
>>> done...
>>> 
>>> Even in the browser, I think Google has figured out what Java folks knew 20 
>>> years ago, JS is a mess, and having a VM in the browser is the way to go. 
>>> WebAssembly is the poor mans Java applet. We’re coming full circle…
>>> 
>>> So to sum up, 100% backwards compatibility is a key to Go’s dominance 
>>> moving forward, again IMO )
>>> 
>>> 
>>> 
>>> 
>>> --
>>> 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.

-- 
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] Q16.16 fixed point numbers in go

[Michael Jones]

https://en.wikipedia.org/wiki/Q_(number_format) says it all.

you can use fixed point all the way...just shift after multiplies and
before divides and use double-width (int32) or wider math.

On Mon, Oct 22, 2018 at 3:24 PM Vasiliy Tolstov  wrote:

> Thanks for suggestions.
> If somebody can look at github.com/unistack-org/go-crush package
> (ported ceph crush to go) i'l be happy.
> Now weight represented as float32, i'm try to use
> https://github.com/shopspring/decimal but code looks ugly with many
> conversations. And also as i see ceph code (mapper.c for crush) they
> does not use something
> different for weights but uint32. may be i miss something but i don't
> understand how they deal with weights like 0.580 in such cases.
> So if somebody wants to help - i'l be happy.
> пн, 22 окт. 2018 г. в 17:14, 'Ingo Oeser' via golang-nuts
> :
> >
> > https://godoc.org/golang.org/x/image/math/fixed might provide some
> hints how to work with this kind of type.
> >
> > The idea is to use a special type and provide all operations you need.
> >
> > https://godoc.org/math/big#Rat might be helpful to create first tests
> of the basic math operations with maximum precision, before reducing
> precision with a conversion to a more limited data type.
> >
> > --
> > 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.
>
>
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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.
>


-- 

*Michael T. jonesmichael.jo...@gmail.com *

-- 
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] Regarding contracts

[Burak Serdar]

On Wed, Oct 24, 2018 at 10:22 AM Andy Balholm  wrote:
>
> Here’s my attempt at streamlining it, as well as adding a way to deal with 
> the operator/method dichotomy: 
> https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2

Thanks!

However,  I think yours is a somewhat different approach altogether.
The main idea I have is that existing types should be used as
contracts.  That means no operators in contracts.

Also: when you list types in a contract:

contract X {
  T1
  T2
}

I defined it to mean that any type satisfying X must satisfy both T1 and T2.

And with "like" type contract specifications (enumerated contracts)

contract X like(int,int8,int16...)

A type satisfying X is a derivative of any one of the types listed. So
it is possible to write:

contract StrNum {
   like(int, int8, int16,...)
   interface {
  String() string
   }
}

meaning StrNum must be an integer that implements String()

The "type switch" for contracts imply that contracts are a runtime
construct. In my case, contracts are purely compile time.


>
> Andy
>
> On Oct 23, 2018, at 9:37 AM, Burak Serdar  wrote:
>
> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar  wrote:
>
>
> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich  wrote:
>
>
> * Burak Serdar  [181018 15:08]:
>
> tbh, I am not trying to avoid operator overloading, I am trying to
> avoid the contracts. With operator overloading, you can write:
>
> func F(a,b type T like(int,X)) {
>   if a ...
>   }
> }
>
> provided X is a type that supports <.
>
>
> Are you trying to avoid the concept of contracts or the specific syntax
> proposed in the design draft?
>
>
>
> My intent was to use existing types as contracts instead of an
> abstract contract specification. In this scenario, a contract is a
> more abstract concept that an interface. Above, type T like(int,X)
> would mean:
>  - func F compiles for T=int and T=X
>  - F can be instantiated for any type derived from int or X
> So instead of specifying the precise type semantics required by F,
> you'd approximate the intent and declare that F would work for types
> that look like int, and X.
>
> When you apply the same idea to structs:
>
> type T like struct {a, b, int}
>
> would mean that T can be substituted by any struct containing two int
> fields called a and b.
>
> This idea ran into problems later on: I cannot explain simple
> contracts such as "type T must support ==".
>
>
>
> I typed this up in a more organized way, and it turned out to be an
> alternative declaration for contracts without touching the generics
> parts of the proposal.
>
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
>
> --
> 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] Go 2 Proposal Comments

[robert engels]

Also, I wouldn’t discount the ‘binary runs with the latest JVM’ doesn’t apply 
to Go.

As I pointed out in an earlier email, I think the future of Go is that the 
shipped binary will be runtime linked against the standard library and runtime. 
This is by far the easier way to deliver security patches. You will probably 
pay a performance hit due to lack of inlining, but for a large class of 
applications this would be a easy trade-off to make to simplify security 
handling.

> On Oct 24, 2018, at 11:26 AM, Burak Serdar  wrote:
> 
> On Wed, Oct 24, 2018 at 10:21 AM robert engels  wrote:
>> 
>> I think enum was a reserved word from the beginning - like goto - if not it 
>> was VERY early on when it was added. Still, the code would of run on the 
>> latest JVM, it might not of compiled. Outside of that possible case, I can’t 
>> think of another keyword that has been added - maybe the recent addition of 
>> ‘var’ - but don’t get me started on what it happening with Java now - I 
>> think there are very different forces at work than the founding principles.
> 
> You might be right on the history of "enum", but the point is that any
> time you add a keyword, something breaks.
> 
> The point that old code can run on new JVM is inapplicable in my
> opinion when comparing Java and Go.
> 
> Also, it may not always be a good thing to preserve backward
> compatibility. Opinions differ on this, but I think generics in Java
> is a convoluted piece of mess.
> 
>> 
>> On Oct 24, 2018, at 11:12 AM, Burak Serdar  wrote:
>> 
>> On Wed, Oct 24, 2018 at 9:59 AM robert engels  wrote:
>> 
>> 
>> To this day, you can take a “binary” written for Java 1.0 and it will run 
>> under the latest JRE. You can compile Java 1.0 source code with the latest 
>> compiler. This is an amazing accomplishment that can’t be understated.
>> 
>> 
>> That is not exactly true, is it? Any time a new keyword is added to
>> the language something breaks. They added "enum" at some point, and
>> all programs using enum as an identifier stopped compiling.
>> 
>> 
>> Over the years, with the benefit of hindsight, many of the Java APIs were 
>> deemed insufficient, or better designs emerged, and they were deprecated, 
>> with the warning, "may be removed in a future release”.
>> 
>> To my knowledge a deprecated API in the stdlib has never been removed. The 
>> “deprecation” label is more of a “hey, there are better ways of doing this, 
>> and you should use them…”.
>> 
>> I think Go would be best served by ensuring that any future release is 100% 
>> backwards compatible with previous releases. This is the number one aspect 
>> of Java (IMO) that lead to its success - it drastically reduced the 
>> churn/expense of delivering software. Businesses like this…. Developers like 
>> this...
>> 
>> In the end, if Go can deliver on the cross platform (some of the OS specific 
>> APIs were a bad choice in some ways IMO, although it is not a deal breaker), 
>> and the 100% backwards compatibility, I don’t see any reason why Go couldn’t 
>> become as ubiquitous as Java.
>> 
>> I believe in the end there will two languages left standing. Java for 
>> enterprise apps, and Go for system tools, services, and even OS building. It 
>> is nearly 2020 - manual memory management is done, dynamic languages are 
>> done...
>> 
>> Even in the browser, I think Google has figured out what Java folks knew 20 
>> years ago, JS is a mess, and having a VM in the browser is the way to go. 
>> WebAssembly is the poor mans Java applet. We’re coming full circle…
>> 
>> So to sum up, 100% backwards compatibility is a key to Go’s dominance moving 
>> forward, again IMO )
>> 
>> 
>> 
>> 
>> --
>> 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] Go 2 Proposal Comments

[Burak Serdar]

On Wed, Oct 24, 2018 at 10:21 AM robert engels  wrote:
>
> I think enum was a reserved word from the beginning - like goto - if not it 
> was VERY early on when it was added. Still, the code would of run on the 
> latest JVM, it might not of compiled. Outside of that possible case, I can’t 
> think of another keyword that has been added - maybe the recent addition of 
> ‘var’ - but don’t get me started on what it happening with Java now - I think 
> there are very different forces at work than the founding principles.

You might be right on the history of "enum", but the point is that any
time you add a keyword, something breaks.

The point that old code can run on new JVM is inapplicable in my
opinion when comparing Java and Go.

Also, it may not always be a good thing to preserve backward
compatibility. Opinions differ on this, but I think generics in Java
is a convoluted piece of mess.

>
> On Oct 24, 2018, at 11:12 AM, Burak Serdar  wrote:
>
> On Wed, Oct 24, 2018 at 9:59 AM robert engels  wrote:
>
>
> To this day, you can take a “binary” written for Java 1.0 and it will run 
> under the latest JRE. You can compile Java 1.0 source code with the latest 
> compiler. This is an amazing accomplishment that can’t be understated.
>
>
> That is not exactly true, is it? Any time a new keyword is added to
> the language something breaks. They added "enum" at some point, and
> all programs using enum as an identifier stopped compiling.
>
>
> Over the years, with the benefit of hindsight, many of the Java APIs were 
> deemed insufficient, or better designs emerged, and they were deprecated, 
> with the warning, "may be removed in a future release”.
>
> To my knowledge a deprecated API in the stdlib has never been removed. The 
> “deprecation” label is more of a “hey, there are better ways of doing this, 
> and you should use them…”.
>
> I think Go would be best served by ensuring that any future release is 100% 
> backwards compatible with previous releases. This is the number one aspect of 
> Java (IMO) that lead to its success - it drastically reduced the 
> churn/expense of delivering software. Businesses like this…. Developers like 
> this...
>
> In the end, if Go can deliver on the cross platform (some of the OS specific 
> APIs were a bad choice in some ways IMO, although it is not a deal breaker), 
> and the 100% backwards compatibility, I don’t see any reason why Go couldn’t 
> become as ubiquitous as Java.
>
> I believe in the end there will two languages left standing. Java for 
> enterprise apps, and Go for system tools, services, and even OS building. It 
> is nearly 2020 - manual memory management is done, dynamic languages are 
> done...
>
> Even in the browser, I think Google has figured out what Java folks knew 20 
> years ago, JS is a mess, and having a VM in the browser is the way to go. 
> WebAssembly is the poor mans Java applet. We’re coming full circle…
>
> So to sum up, 100% backwards compatibility is a key to Go’s dominance moving 
> forward, again IMO )
>
>
>
>
> --
> 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] Regarding contracts

[Andy Balholm]

Here’s my attempt at streamlining it, as well as adding a way to deal with the 
operator/method dichotomy: 
https://gist.github.com/andybalholm/8165da83c10a48e56590c96542e93ff2 


Andy

> On Oct 23, 2018, at 9:37 AM, Burak Serdar  wrote:
> 
> On Mon, Oct 22, 2018 at 2:10 PM Burak Serdar  wrote:
>> 
>> On Mon, Oct 22, 2018 at 1:53 PM Marvin Renich  wrote:
>>> 
>>> * Burak Serdar  [181018 15:08]:
 tbh, I am not trying to avoid operator overloading, I am trying to
 avoid the contracts. With operator overloading, you can write:
 
 func F(a,b type T like(int,X)) {
   if a>>> ...
   }
 }
 
 provided X is a type that supports <.
>>> 
>>> Are you trying to avoid the concept of contracts or the specific syntax
>>> proposed in the design draft?
>> 
>> 
>> My intent was to use existing types as contracts instead of an
>> abstract contract specification. In this scenario, a contract is a
>> more abstract concept that an interface. Above, type T like(int,X)
>> would mean:
>>  - func F compiles for T=int and T=X
>>  - F can be instantiated for any type derived from int or X
>> So instead of specifying the precise type semantics required by F,
>> you'd approximate the intent and declare that F would work for types
>> that look like int, and X.
>> 
>> When you apply the same idea to structs:
>> 
>> type T like struct {a, b, int}
>> 
>> would mean that T can be substituted by any struct containing two int
>> fields called a and b.
>> 
>> This idea ran into problems later on: I cannot explain simple
>> contracts such as "type T must support ==".
> 
> 
> I typed this up in a more organized way, and it turned out to be an
> alternative declaration for contracts without touching the generics
> parts of the proposal.
> 
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3
> 
> -- 
> 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] Go 2 Proposal Comments

[robert engels]

I think enum was a reserved word from the beginning - like goto - if not it was 
VERY early on when it was added. Still, the code would of run on the latest 
JVM, it might not of compiled. Outside of that possible case, I can’t think of 
another keyword that has been added - maybe the recent addition of ‘var’ - but 
don’t get me started on what it happening with Java now - I think there are 
very different forces at work than the founding principles.

> On Oct 24, 2018, at 11:12 AM, Burak Serdar  wrote:
> 
> On Wed, Oct 24, 2018 at 9:59 AM robert engels  > wrote:
>> 
>> To this day, you can take a “binary” written for Java 1.0 and it will run 
>> under the latest JRE. You can compile Java 1.0 source code with the latest 
>> compiler. This is an amazing accomplishment that can’t be understated.
> 
> That is not exactly true, is it? Any time a new keyword is added to
> the language something breaks. They added "enum" at some point, and
> all programs using enum as an identifier stopped compiling.
> 
>> 
>> Over the years, with the benefit of hindsight, many of the Java APIs were 
>> deemed insufficient, or better designs emerged, and they were deprecated, 
>> with the warning, "may be removed in a future release”.
>> 
>> To my knowledge a deprecated API in the stdlib has never been removed. The 
>> “deprecation” label is more of a “hey, there are better ways of doing this, 
>> and you should use them…”.
>> 
>> I think Go would be best served by ensuring that any future release is 100% 
>> backwards compatible with previous releases. This is the number one aspect 
>> of Java (IMO) that lead to its success - it drastically reduced the 
>> churn/expense of delivering software. Businesses like this…. Developers like 
>> this...
>> 
>> In the end, if Go can deliver on the cross platform (some of the OS specific 
>> APIs were a bad choice in some ways IMO, although it is not a deal breaker), 
>> and the 100% backwards compatibility, I don’t see any reason why Go couldn’t 
>> become as ubiquitous as Java.
>> 
>> I believe in the end there will two languages left standing. Java for 
>> enterprise apps, and Go for system tools, services, and even OS building. It 
>> is nearly 2020 - manual memory management is done, dynamic languages are 
>> done...
>> 
>> Even in the browser, I think Google has figured out what Java folks knew 20 
>> years ago, JS is a mess, and having a VM in the browser is the way to go. 
>> WebAssembly is the poor mans Java applet. We’re coming full circle…
>> 
>> So to sum up, 100% backwards compatibility is a key to Go’s dominance moving 
>> forward, again IMO )
>> 
>> 
>> 
>> 
>> --
>> 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] interface array and ... operator

[robert engels]

I quote

So in the OP's example https://play.golang.org/p/59bpr8TCIge 
, the function A() is assigning a 
[]string to the variadic ...[]interface{}. Since string is assignable to 
interface{}. this is fine. The function B() is assigning a []interface{} to the 
variadic of ...[]string. Since interface{} is not assignable to string, this is 
not allowed. 


> On Oct 24, 2018, at 11:08 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> Nobody said that.
> 
> On Wed, Oct 24, 2018, 18:04 robert engels  > wrote:
> I’m confused… it is A that doesn’t work, and B works… everyone keeps stating 
> that B doesn’t work and A works….
> 
>> On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com  
>> wrote:
> 
>> 
>> That is correct. The relevant part of 
>> https://golang.org/ref/spec#Passing_arguments_to_..._parameters 
>>  is where 
>> it says: " respective parameter passing rules 
>> apply". 
>> This links to 
>> https://golang.org/ref/spec#Passing_arguments_to_..._parameters 
>>  which says:
>> 
>> "Otherwise, the value passed is a new slice of type []T with a new 
>> underlying array whose successive elements are the actual arguments, which 
>> all must be assignable  to T."
>> 
>> So in the OP's example https://play.golang.org/p/59bpr8TCIge 
>> , the function A() is assigning a 
>> []string to the variadic ...[]interface{}. Since string is assignable to 
>> interface{}. this is fine. The function B() is assigning a []interface{} to 
>> the variadic of ...[]string. Since interface{} is not assignable to string, 
>> this is not allowed. 
>> 
>> Hope that clarifies. 
>> 
>> 
>> On Wednesday, October 24, 2018 at 9:11:50 AM UTC-4, Robert Engels wrote:
>> But it is the varadic one that works according to OP. 
>> 
>> On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@ <>gmail.com 
>> > wrote:
>> 
>>> On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha gmail.com 
>>> > wrote:
>>> 
>>> > why does A() not work while B works here, 
>>> > https://play.golang.org/p/59bpr8TCIge 
>>> >  
>>> 
>>> Type mismatch. The compiler is clear about it:
>>> 
>>> prog.go:8:12: cannot use s (type []string) as type []interface {} 
>>> in append
>>> 
>>> From https://golang.org/ref/spec#Appending_and_copying_slices 
>>> 
>>> 
>>> 
>>> The variadic function append appends zero or more values x to s of type S, 
>>> which must be a slice type, 
>>> and returns the resulting slice, also of type S. The values x are passed to 
>>> a parameter of type ...T
>>> where T is the element typeof S and the respective parameter passing rules 
>>> apply. As a special case,
>>> append also accepts a first argument assignable to type []byte with a 
>>> second argument of string type
>>> followed by  This form appends the bytes of the string.
>>> ---
>>> 
>>> In the OP code, type T is `interface{}`, but the appended elements have 
>>> type `string`. That violates the above quoted specs.
>>> 
>>> 
>>> -- 
>>> -j
>>> 
>>> 
>>> -- 
>>> 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 
>> .
> 
> 
> -- 
> 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 
> .
> -- 
> -j
> 

-- 
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] interface array and ... operator

[Jan Mercl]

Eh, actially the other discusser said that. Me not. I explained why A does
not work.

On Wed, Oct 24, 2018, 18:08 Jan Mercl <0xj...@gmail.com> wrote:

> Nobody said that.
>
> On Wed, Oct 24, 2018, 18:04 robert engels  wrote:
>
>> I’m confused… it is A that doesn’t work, and B works… everyone keeps
>> stating that B doesn’t work and A works….
>>
>> On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote:
>>
>>
>> That is correct. The relevant part of
>> https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where
>> it says: " respective parameter passing rules
>> apply".
>> This links to
>> https://golang.org/ref/spec#Passing_arguments_to_..._parameters which
>> says:
>>
>> "Otherwise, the value passed is a new slice of type []T with a new
>> underlying array whose successive elements are the actual arguments, which
>> all must be assignable  to T."
>>
>> So in the OP's example https://play.golang.org/p/59bpr8TCIge, the
>> function A() is assigning a []string to the variadic ...[]interface{}.
>> Since string is assignable to interface{}. this is fine. The function B()
>> is assigning a []interface{} to the variadic of ...[]string. Since
>> interface{} is *not *assignable to string, this is not allowed.
>>
>> Hope that clarifies.
>>
>>
>> On Wednesday, October 24, 2018 at 9:11:50 AM UTC-4, Robert Engels wrote:
>>>
>>> But it is the varadic one that works according to OP.
>>>
>>> On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>>
>>> On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha  wrote:
>>>
>>> > why does A() not work while B works here,
>>> https://play.golang.org/p/59bpr8TCIge
>>>
>>> Type mismatch. The compiler is clear about it:
>>>
>>> prog.go:8:12: cannot use s (type []string) as type []interface
>>> {} in append
>>>
>>> From https://golang.org/ref/spec#Appending_and_copying_slices
>>>
>>> 
>>> The variadic function append appends zero or more values x to s of type
>>> S, which must be a slice type,
>>> and returns the resulting slice, also of type S. The values x are passed
>>> to a parameter of type ...T
>>> where T is the element typeof S and the respective parameter passing
>>> rules apply. As a special case,
>>> append also accepts a first argument assignable to type []byte with a
>>> second argument of string type
>>> followed by  This form appends the bytes of the string.
>>> ---
>>>
>>> In the OP code, type T is `interface{}`, but the appended elements have
>>> type `string`. That violates the above quoted specs.
>>>
>>>
>>> --
>>>
>>> -j
>>>
>>> --
>>> 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.
>>
>>
>> --
>> 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.
>>
> --
>
> -j
>
-- 

-j

-- 
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] Go 2 Proposal Comments

[Burak Serdar]

On Wed, Oct 24, 2018 at 9:59 AM robert engels  wrote:
>
> To this day, you can take a “binary” written for Java 1.0 and it will run 
> under the latest JRE. You can compile Java 1.0 source code with the latest 
> compiler. This is an amazing accomplishment that can’t be understated.

That is not exactly true, is it? Any time a new keyword is added to
the language something breaks. They added "enum" at some point, and
all programs using enum as an identifier stopped compiling.

>
> Over the years, with the benefit of hindsight, many of the Java APIs were 
> deemed insufficient, or better designs emerged, and they were deprecated, 
> with the warning, "may be removed in a future release”.
>
> To my knowledge a deprecated API in the stdlib has never been removed. The 
> “deprecation” label is more of a “hey, there are better ways of doing this, 
> and you should use them…”.
>
> I think Go would be best served by ensuring that any future release is 100% 
> backwards compatible with previous releases. This is the number one aspect of 
> Java (IMO) that lead to its success - it drastically reduced the 
> churn/expense of delivering software. Businesses like this…. Developers like 
> this...
>
> In the end, if Go can deliver on the cross platform (some of the OS specific 
> APIs were a bad choice in some ways IMO, although it is not a deal breaker), 
> and the 100% backwards compatibility, I don’t see any reason why Go couldn’t 
> become as ubiquitous as Java.
>
> I believe in the end there will two languages left standing. Java for 
> enterprise apps, and Go for system tools, services, and even OS building. It 
> is nearly 2020 - manual memory management is done, dynamic languages are 
> done...
>
> Even in the browser, I think Google has figured out what Java folks knew 20 
> years ago, JS is a mess, and having a VM in the browser is the way to go. 
> WebAssembly is the poor mans Java applet. We’re coming full circle…
>
> So to sum up, 100% backwards compatibility is a key to Go’s dominance moving 
> forward, again IMO )
>
>
>
>
> --
> 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] interface array and ... operator

[Jan Mercl]

Nobody said that.

On Wed, Oct 24, 2018, 18:04 robert engels  wrote:

> I’m confused… it is A that doesn’t work, and B works… everyone keeps
> stating that B doesn’t work and A works….
>
> On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote:
>
>
> That is correct. The relevant part of
> https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where
> it says: " respective parameter passing rules
> apply".
> This links to
> https://golang.org/ref/spec#Passing_arguments_to_..._parameters which
> says:
>
> "Otherwise, the value passed is a new slice of type []T with a new
> underlying array whose successive elements are the actual arguments, which
> all must be assignable  to T."
>
> So in the OP's example https://play.golang.org/p/59bpr8TCIge, the
> function A() is assigning a []string to the variadic ...[]interface{}.
> Since string is assignable to interface{}. this is fine. The function B()
> is assigning a []interface{} to the variadic of ...[]string. Since
> interface{} is *not *assignable to string, this is not allowed.
>
> Hope that clarifies.
>
>
> On Wednesday, October 24, 2018 at 9:11:50 AM UTC-4, Robert Engels wrote:
>>
>> But it is the varadic one that works according to OP.
>>
>> On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>
>> On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha  wrote:
>>
>> > why does A() not work while B works here,
>> https://play.golang.org/p/59bpr8TCIge
>>
>> Type mismatch. The compiler is clear about it:
>>
>> prog.go:8:12: cannot use s (type []string) as type []interface
>> {} in append
>>
>> From https://golang.org/ref/spec#Appending_and_copying_slices
>>
>> 
>> The variadic function append appends zero or more values x to s of type
>> S, which must be a slice type,
>> and returns the resulting slice, also of type S. The values x are passed
>> to a parameter of type ...T
>> where T is the element typeof S and the respective parameter passing
>> rules apply. As a special case,
>> append also accepts a first argument assignable to type []byte with a
>> second argument of string type
>> followed by  This form appends the bytes of the string.
>> ---
>>
>> In the OP code, type T is `interface{}`, but the appended elements have
>> type `string`. That violates the above quoted specs.
>>
>>
>> --
>>
>> -j
>>
>> --
>> 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.
>
>
> --
> 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.
>
-- 

-j

-- 
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] interface array and ... operator

[robert engels]

I’m confused… it is A that doesn’t work, and B works… everyone keeps stating 
that B doesn’t work and A works….

> On Oct 24, 2018, at 10:55 AM, jake6...@gmail.com wrote:
> 
> That is correct. The relevant part of 
> https://golang.org/ref/spec#Passing_arguments_to_..._parameters 
>  is where it 
> says: " respective parameter passing rules 
> apply". This 
> links to https://golang.org/ref/spec#Passing_arguments_to_..._parameters 
>  which says:
> 
> "Otherwise, the value passed is a new slice of type []T with a new underlying 
> array whose successive elements are the actual arguments, which all must be 
> assignable  to T."
> 
> So in the OP's example https://play.golang.org/p/59bpr8TCIge 
> , the function A() is assigning a 
> []string to the variadic ...[]interface{}. Since string is assignable to 
> interface{}. this is fine. The function B() is assigning a []interface{} to 
> the variadic of ...[]string. Since interface{} is not assignable to string, 
> this is not allowed. 
> 
> Hope that clarifies. 
> 
> 
> On Wednesday, October 24, 2018 at 9:11:50 AM UTC-4, Robert Engels wrote:
> But it is the varadic one that works according to OP. 
> 
> On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@ <>gmail.com 
> > wrote:
> 
>> On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha gmail.com 
>> > wrote:
>> 
>> > why does A() not work while B works here, 
>> > https://play.golang.org/p/59bpr8TCIge 
>> >  
>> 
>> Type mismatch. The compiler is clear about it:
>> 
>> prog.go:8:12: cannot use s (type []string) as type []interface {} in 
>> append
>> 
>> From https://golang.org/ref/spec#Appending_and_copying_slices 
>> 
>> 
>> 
>> The variadic function append appends zero or more values x to s of type S, 
>> which must be a slice type, 
>> and returns the resulting slice, also of type S. The values x are passed to 
>> a parameter of type ...T
>> where T is the element typeof S and the respective parameter passing rules 
>> apply. As a special case,
>> append also accepts a first argument assignable to type []byte with a second 
>> argument of string type
>> followed by  This form appends the bytes of the string.
>> ---
>> 
>> In the OP code, type T is `interface{}`, but the appended elements have type 
>> `string`. That violates the above quoted specs.
>> 
>> 
>> -- 
>> -j
>> 
>> 
>> -- 
>> 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 
> .

-- 
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 2 Proposal Comments

[robert engels]

I'd like to offer a few comments on Ian's 
https://github.com/golang/proposal/blob/master/design/28221-go2-transitions.md 


Since the author admits the least amount of experience with Java, maybe my 
facts, and many opinions, might offer some insight.

If you head back to the genesis time of Java, there was a dominant tech company 
that produced the dominant OS and associated development tools. It was a “their 
way of or the highway” scenario. Almost like clockwork, every OS change was not 
backwards compatible, at least from the point of, if you wanted to use the new 
feature in the latest OS, you needed to use new APIs for even the “old stuff”. 
So development teams and businesses were in this continuous cycle of rewriting 
the same code for a new API, every few years, all without delivering any new 
value. Couple this with, you had to be “current” in order to get “support”, and 
it’s easy to see the strangle hold they had on an industry.

When Java came along there was a heavy sigh of relief by ISVs that understood 
write-once, and it will continue to work even as mega company released new OS 
versions and APIs - the burden was on the JDK/JRE implementation to make sure 
it worked - not the business. The write-once run “anywhere” was icing on the 
cake - it opened doors to some markets very cheaply.

To this day, you can take a “binary” written for Java 1.0 and it will run under 
the latest JRE. You can compile Java 1.0 source code with the latest compiler. 
This is an amazing accomplishment that can’t be understated.

Over the years, with the benefit of hindsight, many of the Java APIs were 
deemed insufficient, or better designs emerged, and they were deprecated, with 
the warning, "may be removed in a future release”.

To my knowledge a deprecated API in the stdlib has never been removed. The 
“deprecation” label is more of a “hey, there are better ways of doing this, and 
you should use them…”.

I think Go would be best served by ensuring that any future release is 100% 
backwards compatible with previous releases. This is the number one aspect of 
Java (IMO) that lead to its success - it drastically reduced the churn/expense 
of delivering software. Businesses like this…. Developers like this...

In the end, if Go can deliver on the cross platform (some of the OS specific 
APIs were a bad choice in some ways IMO, although it is not a deal breaker), 
and the 100% backwards compatibility, I don’t see any reason why Go couldn’t 
become as ubiquitous as Java.

I believe in the end there will two languages left standing. Java for 
enterprise apps, and Go for system tools, services, and even OS building. It is 
nearly 2020 - manual memory management is done, dynamic languages are done...

Even in the browser, I think Google has figured out what Java folks knew 20 
years ago, JS is a mess, and having a VM in the browser is the way to go. 
WebAssembly is the poor mans Java applet. We’re coming full circle…

So to sum up, 100% backwards compatibility is a key to Go’s dominance moving 
forward, again IMO )




-- 
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] interface array and ... operator

[jake6502]

That is correct. The relevant part of 
https://golang.org/ref/spec#Passing_arguments_to_..._parameters is where it 
says: " respective parameter passing rules 
 apply". 
This links to 
https://golang.org/ref/spec#Passing_arguments_to_..._parameters which says:

"Otherwise, the value passed is a new slice of type []T with a new 
underlying array whose successive elements are the actual arguments, which 
all must be assignable  to T."

So in the OP's example https://play.golang.org/p/59bpr8TCIge, the function 
A() is assigning a []string to the variadic ...[]interface{}. Since string 
is assignable to interface{}. this is fine. The function B() is assigning a 
[]interface{} to the variadic of ...[]string. Since interface{} is *not 
*assignable 
to string, this is not allowed. 

Hope that clarifies. 


On Wednesday, October 24, 2018 at 9:11:50 AM UTC-4, Robert Engels wrote:
>
> But it is the varadic one that works according to OP. 
>
> On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com > 
> wrote:
>
> On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha  > wrote:
>
> > why does A() not work while B works here, 
> https://play.golang.org/p/59bpr8TCIge 
>
> Type mismatch. The compiler is clear about it:
>
> prog.go:8:12: cannot use s (type []string) as type []interface {} 
> in append
>
> From https://golang.org/ref/spec#Appending_and_copying_slices
>
> 
> The variadic function append appends zero or more values x to s of type S, 
> which must be a slice type, 
> and returns the resulting slice, also of type S. The values x are passed 
> to a parameter of type ...T
> where T is the element typeof S and the respective parameter passing rules 
> apply. As a special case,
> append also accepts a first argument assignable to type []byte with a 
> second argument of string type
> followed by  This form appends the bytes of the string.
> ---
>
> In the OP code, type T is `interface{}`, but the appended elements have 
> type `string`. That violates the above quoted specs.
>
>
> -- 
>
> -j
>
> -- 
> 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] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alan . fox6]

Hmm, interesting idea!

Presumably, that would still work if 'check' were declared as a local 
variable within the same function *after* all the error handling stuff, as 
the compiler would detect it on first pass.

I wondered myself about having some sort of pragma or pseudo-import (say: 
import . "E") at top level within the package to turn the new error 
handling on but as that would be a new feature in itself perhaps it's not 
such a good idea.

Alan

On Wednesday, October 24, 2018 at 3:22:03 PM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Oct 24, 2018 at 3:49 AM, alanfo > 
> wrote: 
> > 
> > I quite like the draft error handling design and haven't (so far) 
> suggested 
> > that any changes be made. 
> > 
> > However, one aspect I don't like is 'check' and 'handle' having to be 
> > keywords which means that the design is not Go 1 compatible. Also, 
> whilst I 
> > agree that these words are probably the best ones for the job (and I 
> would 
> > hate to see them replaced by obscure symbols) it seems a pity that such 
> > commonly used words will no longer be available as ordinary identifiers. 
> > 
> > So all I'm asking here is whether - if the design were adopted as it 
> stands 
> > - they could be 'contextual' rather than 'full' keywords? I couldn't 
> find 
> > any mention of this in the draft papers but apologize in advance if it's 
> > been addressed and I've missed it. 
> > 
> > As far as this thread is concerned, I'm only interested in this question 
> and 
> > not what people think of the design generally. 
> > 
> > It seems to me that they probably could be 'contextual' keywords i.e. 
> they 
> > could still be used as ordinary identifiers in the same package or even 
> > within the same function (though the latter wouldn't be a great idea 
> from a 
> > readability perspective). 
> > 
> > Considering first 'handle' which must be the first word in a line and 
> then 
> > be followed by an identifier. It cannot be any of the following: 
> > 
> > 1. A function call because its not followed by (. 
> > 
> > 2. An assignment because it's not followed by an =, :=  or , token. 
> > 
> > 3. An indexation expression because it's not followed by [. 
> > 
> > 4. A struct literal because it's not (directly) followed by {. 
> > 
> > 5. Any other expression because it's not followed by an operator. 
> > 
> > So can anyone think of anything else it could be? 
> > 
> > However, 'check' is more awkward because it's followed by an expression 
> (not 
> > an identifier) and need not be the first word in the line. If the 
> expression 
> > were bracketed or preceded by a unary operator then there would be a 
> > potential ambiguity with #1 or #5 respectively. 
> > 
> > So would it suffice for the compiler to try and interpret 'check' in 
> these 
> > situations as a 'normal' identifier and issue an error if it couldn't 
> but 
> > otherwise to interpret it as a error handling keyword? 
> > 
> > The error would of course be easy enough to fix but, even if there are 
> no 
> > other ambiguities, would it just be too confusing and should we simply 
> > accept that 'check' has to be a 'full' keyword as the design stands? 
>
> I think that if a package does define `check` as a local function, 
> then making contextual choices about whether `check` in an expression 
> refers to the function or to the error checking behavior can only be 
> confusing. 
>
> One approach that could perhaps work--and I'm not at all endorsing 
> this, just pointing it out--is that if a package defines `check` as a 
> local name of any sort, the compiler could simply disable the error 
> checking behavior of `check`.  That is, `check` would only be a 
> keyword if there were no local definition of `check`. 
>
> 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] liteide x35 released! Go1.11 modules support.

[visualfc]

Please download LiteIDE x35.1Fix gocode types info parse source \r\n bug. 
Fix Golang editor jump import lines bug. 

-- 
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] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[Ian Lance Taylor]

On Wed, Oct 24, 2018 at 3:49 AM, alanfo  wrote:
>
> I quite like the draft error handling design and haven't (so far) suggested
> that any changes be made.
>
> However, one aspect I don't like is 'check' and 'handle' having to be
> keywords which means that the design is not Go 1 compatible. Also, whilst I
> agree that these words are probably the best ones for the job (and I would
> hate to see them replaced by obscure symbols) it seems a pity that such
> commonly used words will no longer be available as ordinary identifiers.
>
> So all I'm asking here is whether - if the design were adopted as it stands
> - they could be 'contextual' rather than 'full' keywords? I couldn't find
> any mention of this in the draft papers but apologize in advance if it's
> been addressed and I've missed it.
>
> As far as this thread is concerned, I'm only interested in this question and
> not what people think of the design generally.
>
> It seems to me that they probably could be 'contextual' keywords i.e. they
> could still be used as ordinary identifiers in the same package or even
> within the same function (though the latter wouldn't be a great idea from a
> readability perspective).
>
> Considering first 'handle' which must be the first word in a line and then
> be followed by an identifier. It cannot be any of the following:
>
> 1. A function call because its not followed by (.
>
> 2. An assignment because it's not followed by an =, :=  or , token.
>
> 3. An indexation expression because it's not followed by [.
>
> 4. A struct literal because it's not (directly) followed by {.
>
> 5. Any other expression because it's not followed by an operator.
>
> So can anyone think of anything else it could be?
>
> However, 'check' is more awkward because it's followed by an expression (not
> an identifier) and need not be the first word in the line. If the expression
> were bracketed or preceded by a unary operator then there would be a
> potential ambiguity with #1 or #5 respectively.
>
> So would it suffice for the compiler to try and interpret 'check' in these
> situations as a 'normal' identifier and issue an error if it couldn't but
> otherwise to interpret it as a error handling keyword?
>
> The error would of course be easy enough to fix but, even if there are no
> other ambiguities, would it just be too confusing and should we simply
> accept that 'check' has to be a 'full' keyword as the design stands?

I think that if a package does define `check` as a local function,
then making contextual choices about whether `check` in an expression
refers to the function or to the error checking behavior can only be
confusing.

One approach that could perhaps work--and I'm not at all endorsing
this, just pointing it out--is that if a package defines `check` as a
local name of any sort, the compiler could simply disable the error
checking behavior of `check`.  That is, `check` would only be a
keyword if there were no local definition of `check`.

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] Calendar Integration Values

[John More]

Thank You.
I was afraid that would be the answer, but my research could not match 
yours. 
I will keep looking; however there does have to be a better way to provide 
API access to outside resources without involving my domain users . I 
always use a service account with DWD enabled and use my admin account to 
access calendars in my domain. 

Thanks
John

On Tuesday, October 23, 2018 at 8:24:36 PM UTC-4, mingle wrote:
>
> John,
>
> Here's what I found.  I believe this private URL includes what Google 
> refers to as a "magic cookie" for authentication.
>
> An old post (from 2008) asks if this can be retrieved via an API, with a 
> response from Google:
>
> https://markmail.org/message/fkqu62uyrmtfb3y4#query:+page:1+mid:fkqu62uyrmtfb3y4+state:results
>
> The magic cookie is not exposed through the API for security reason, it can
>> only be retrieved from going directly into the Calendar UI.
>
>
> While this is pretty old, I've found similar questions from people 
> attempting to do the same as you, and the answers over the years all seem 
> to indicate that this is only exposed via the UI.
>
>
> https://groups.google.com/forum/#!topic/google-calendar-help-dataapi/9Ds8QdaCGFI
> https://support.google.com/code/answer/64253?hl=en
>
> https://stackoverflow.com/questions/5090/retrieve-private-ical-url-for-a-private-calendar-using-the-java-google-calendar
>
> https://stackoverflow.com/questions/6719319/google-api-how-do-i-retrieve-a-calendars-private-address-or-magic-cookie
>
> If you happen to find otherwise, I'd love to know.
>
> Good luck!
> - mingle
>
> On Tue, Oct 23, 2018 at 3:15 PM Caleb Mingle > 
> wrote:
>
>> John,
>>
>> Apologies, I misunderstood your initial question.
>>
>> I wouldn’t be surprised if those values were not exposed via an API, but 
>> I’ll do some research and report back. 
>>
>> - mingle
>>
>> On Tue, Oct 23, 2018 at 13:59 John More > > wrote:
>>
>>> Mingle,
>>> The library I am using is the "google.golang.org/api/calendar/v3" which 
>>> accesses the  https://www.googleapis.com/calendar/v3 REST interface.
>>> I would like to read the secret address of a calendar that I create in a 
>>> G Suite domain user's account so I can dynamically forward it to another 
>>> company that insist they need it to watch for events on the calendar. I 
>>> know it is not appropriate to do this with the private address but this was 
>>> set up before my time and it will be changed but for now history has me 
>>> trapped.
>>> I have tried the API Explorer and I have reviewed the library code and 
>>> can not see where this value is part of any structure.
>>>
>>> Thank you for your reply.
>>>
>>> John
>>>
>>>
>>> On Monday, October 22, 2018 at 12:51:02 AM UTC-4, mingle wrote:

 John,

 Can you provide more details on which "calendar library" you 
 are referring to?

 The link you've highlighted in Google calendar points to a file in 
 iCalendar format. You'll probably want an iCalendar parser to handle the 
 file, I've personally used this one, but it doesn't handle everything in 
 the spec: https://github.com/luxifer/ical.

 Depending on the parser that you choose it may have functionality to 
 fetch a file by URL, but most likely you'll need to perform an HTTP 
 request 
 to that URL, read the body, and pass it to a parser.

 - mingle


 On Sun, Oct 21, 2018 at 5:13 AM John More  
 wrote:

> I can not find any documentation indicating how to retrieve the 
> Calendar Integration Values below. I can create and manipulate calendars 
> add events etc using the calendar library.
> Is it possible that these values are simply not available?
>
> Thanks any assistance is appreciated.
>
> John More
>
> [image: Screenshot from 2018-10-21 08-04-52.png]
>
> -- 
> 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.
>


 -- 
 Caleb Mingle

 mingle.cm | @caleb_io 

>>> -- 
>>> 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.
>>>
>> -- 
>> Caleb Mingle
>>
>> mingle.cm | @caleb_io 
>>
>
>
> -- 
> Caleb Mingle
>
> mingle.cm | @caleb_io 
>

-- 
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, 

Re: [go-nuts] Failed iterator proposals?

['Axel Wagner' via golang-nuts]

On Wed, Oct 24, 2018 at 2:35 PM Eric S. Raymond  wrote:

> Axel Wagner :
> > The key term was "occasionally". I don't know how often "iterators that
> > don't need any error handling or cleanup" comes up, but I'd imagine it to
> > be pretty rare. In Python, for example, this might be a bit different,
> > because the iterator can just throw. And if you actually don't need error
> > handling or cleanup, using a channel seems fine (and on par with any
> > generic iteration construct in terms of LOC).
> >
> > If saving LOC is the goal (TBH I contest that all LOC are created equal
> in
> > this regard) there are much lower hanging fruit.
>
> My "low-hanging fruit" is the real problems I'm encountering
> tranlating 14KLOC of algorithmically dense Python that operates on
> data sets gigabytes wide (translation now 70% complete). I think
> that's a pretty good road test.
>

So, how many such loops are there? Because if I, for example, grep through
all of golang.org/x that I have on my machine right now, less than 2% of
lines contain "for", so I'd say 2% already provides an extremely generous
upper bound of the percentage of SLOC this would save for average Go code.
It's probably a *lot* lower than that as I'd say the vast majority of loops
won't benefit at all from custom iterators. But even 1% is IMO still not a
very important amount of saved SLOC, especially if the saved SLOC are
obvious and unlikely to hide bugs.

You shouldn't assume I don't have ideas about error handling and cleanup
> just bceause you haven't seen them yet.


I did nothing of the sort. I just spoke from my own experience about how
common that is.

Anyway. Feel free to spend more time on this as you see fit. It's yours to
spend, after all.

They's be in a complete  RFE.
> --
> http://www.catb.org/~esr/;>Eric S. Raymond
>
> My work is funded by the Internet Civil Engineering Institute:
> https://icei.org
> Please visit their site and donate: the civilization you save might be
> your own.
>
>
>

-- 
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] interface array and ... operator

[Robert Engels]

But it is the varadic one that works according to OP. 

> On Oct 24, 2018, at 4:19 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha  wrote:
> 
> > why does A() not work while B works here, 
> > https://play.golang.org/p/59bpr8TCIge 
> 
> Type mismatch. The compiler is clear about it:
> 
> prog.go:8:12: cannot use s (type []string) as type []interface {} in 
> append
> 
> From https://golang.org/ref/spec#Appending_and_copying_slices
> 
> 
> The variadic function append appends zero or more values x to s of type S, 
> which must be a slice type, 
> and returns the resulting slice, also of type S. The values x are passed to a 
> parameter of type ...T
> where T is the element typeof S and the respective parameter passing rules 
> apply. As a special case,
> append also accepts a first argument assignable to type []byte with a second 
> argument of string type
> followed by  This form appends the bytes of the string.
> ---
> 
> In the OP code, type T is `interface{}`, but the appended elements have type 
> `string`. That violates the above quoted specs.
> 
> 
> -- 
> -j
> 
> -- 
> 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] Failed iterator proposals?

[Jan Mercl]

On Mon, Oct 22, 2018 at 2:41 AM Eric Raymond  wrote:

> There's an obvious, clumsy way to do this by having a factory pass back a
stateful iterator object:
>
> for iterator := IteratorFactory(selector);
iterator.Continue();iterator.Next(){
>DoSomethingWith(iterator.Value())
> }
>
> What one would really like to be able to do, though, is much more concise:
>
> for i, v := range iteratorFunction() {
>DoSomethingWith(i, v)
> }
>

The 'obvious' way is not something I'd consider. The 'concise' way works
today, provided iterator function returns a slice or a map.

I'd probably write something like

for item := someSetup(selector); item.Next(); {
DoSomethingWith(item)
}

Item type can be whatever is needed, like `struct{i, v int}` or something
much more complex. I don't think that this calls for a language change.

-- 

-j

-- 
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] Powerful text query language GraphQuery

[developer]

GraphQuery [image: CircleCI] 
 [image: Go 
Report Card] 
 [image: 
Build Status]  [image: Coverage 
Status]  
[image: 
GoDoc]  [image: Gitter 
chat] 

[image: GraphQuery]

GraphQuery is a query language and execution engine tied to any backend 
service. It is back-end language independent.

Project Address: GraphQuery 

Related Projects:

   - GraphQuery-PlayGround 
    : Learn and test 
   GraphQuery in an interactive walkthrough
   - Document  : Detailed 
   documentation of GraphQuery
   - GraphQuery-http  : Cross 
   language solution for GraphQuery

Catalog
   
   1. Overview 
   2. Get Start 
   2.1 First Example 
   
   2.2 Pipeline 
   3. Install 
   3.1 Golang 
   3.2 Other Language 

Overview

GraphQuery is an easy to use query language, it has built-in 
Xpath/CSS/Regex/JSONpath selectors and enough built-in text processing 
functions.
The most amazing thing is that you can use the minimalist GraphQuery syntax 
to get any data structure you want.
Language-independent

Use GraphQuery to let you unify text parsing logic on any backend language.
You won't need to find implementations of Xpath/CSS/Regex/JSONpath 
selectors between different languages ​​and get familiar with their syntax 
or explore their compatibility.
Multiple selector syntax support

You can use GraphQuery to parse any text and use your skilled selector. 
GraphQuery currently supports the following selectors:

   1. Jsonpath for parsing JSON strings
   2. Xpath and CSS for parsing XML/HTML
   3. Regular expressions for parsing any text.

You can use these selectors in any combination in GraphQuery.
Complete function

Graphquery has some built-in text processing functions like trim, template, 
replace. If you think these functions don't meet your needs, you can 
register new custom functions in the pipeline.

Getting Started

GraphQuery consists of query language and pipelines. To guide you through 
each of these components, we've written an example designed to illustrate 
the various pieces of GraphQuery. This example is not comprehensive, but it 
is designed to quickly introduce the core concepts of GraphQuery. The 
premise of the example is that we want to use GraphQuery to query for 
information about library books.

1. First example


0836217462
Being a Dog Is a Full-Time Job
I'd dog paddle the deepest ocean.


Charles M Schulz
1922-11-26
2000-02-12


Peppermint Patty
1966-08-22
bold, brash and tomboyish


Snoopy
1950-10-04
extroverted beagle


Faced with such a text structure, we naturally think of extracting the 
following data structure from the text :

{
bookID
title
isbn
quote
language
author{
name
born
dead
}
character [{
name
born
qualification
}]
}

This is perfect, when you know the data structure you want to extract, you 
have actually succeeded 80%, the above is the data structure we want, we 
call it DDL (Data Definition Language) for the time being. let's see how 
GraphQuery does it:

{
bookID `css("book");attr("id")`
title `css("title")`
isbn `xpath("//isbn")`
quote `css("quote")`
language `css("title");attr("lang")`
author `css("author")` {
name `css("name")`
born `css("born")`
dead `css("dead")`
}
character `xpath("//character")` [{
name `css("name")`
born `css("born")`
qualification `xpath("qualification")`
}]
}

As you can see, the syntax of GraphQuery adds some strings wrapped in *`* to 
the DDL. These strings wrapped by *`* are called Pipeline. We will 
introduce Pipeline later. Let's first take a look at what data GraphQuery 
engine returns to us.

{
"bookID": "b0836217462",
"title": "Being a Dog Is a Full-Time Job",
"isbn": "0836217462",
"quote": "I'd dog paddle the deepest ocean.",
"language": "en",
"author": {
"born": "1922-11-26",
"dead": "2000-02-12",
"name": "Charles M Schulz"
},
"character": [
{
"born": "1966-08-22",
"name": "Peppermint Patty",
"qualification": "bold, brash and tomboyish"
},
{
"born": "1950-10-04",
"name": "Snoopy",
"qualification": "extroverted beagle"
}
],
}

Wow, it's wonderful. Just like what we want.
We call the above example Example1, now 

Re: [go-nuts] Failed iterator proposals?

[Eric S. Raymond]

Axel Wagner :
> The key term was "occasionally". I don't know how often "iterators that
> don't need any error handling or cleanup" comes up, but I'd imagine it to
> be pretty rare. In Python, for example, this might be a bit different,
> because the iterator can just throw. And if you actually don't need error
> handling or cleanup, using a channel seems fine (and on par with any
> generic iteration construct in terms of LOC).
> 
> If saving LOC is the goal (TBH I contest that all LOC are created equal in
> this regard) there are much lower hanging fruit.

My "low-hanging fruit" is the real problems I'm encountering
tranlating 14KLOC of algorithmically dense Python that operates on
data sets gigabytes wide (translation now 70% complete). I think
that's a pretty good road test.

You shouldn't assume I don't have ideas about error handling and cleanup
just bceause you haven't seen them yet. They's be in a complete  RFE.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.


-- 
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] websocket implentation in golang

[sakthi apr]

Hi,

I'm developing web socket in golang that checks the database changes like 
new data insert. 

if the new record added in table user will get notified at client side.

Anyone have idea plz share with me.


Thanks

-- 
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] Draft error handling design - could 'check' and 'handle' be 'contextual' keywords?

[alanfo]

I quite like the draft error handling design and haven't (so far) suggested 
that any changes be made.

However, one aspect I don't like is 'check' and 'handle' having to be 
keywords which means that the design is not Go 1 compatible. Also, whilst I 
agree that these words are probably the best ones for the job (and I would 
hate to see them replaced by obscure symbols) it seems a pity that such 
commonly used words will no longer be available as ordinary identifiers.

So all I'm asking here is whether - *if the design were adopted as it 
stands* - they could be 'contextual' rather than 'full' keywords? I 
couldn't find any mention of this in the draft papers but apologize in 
advance if it's been addressed and I've missed it.

As far as this thread is concerned, I'm only interested in this question 
and not what people think of the design generally.

It seems to me that they probably could be 'contextual' keywords i.e. they 
could still be used as ordinary identifiers in the same package or even 
within the same function (though the latter wouldn't be a great idea from a 
readability perspective).

Considering first 'handle' which must be the first word in a line and then 
be followed by an identifier. It cannot be any of the following:

1. A function call because its not followed by (.

2. An assignment because it's not followed by an =, :=  or , token.

3. An indexation expression because it's not followed by [.

4. A struct literal because it's not (directly) followed by {.

5. Any other expression because it's not followed by an operator.  

So can anyone think of anything else it could be?

However, 'check' is more awkward because it's followed by an expression 
(not an identifier) and need not be the first word in the line. If the 
expression were bracketed or preceded by a unary operator then there would 
be a potential ambiguity with #1 or #5 respectively.

So would it suffice for the compiler to try and interpret 'check' in these 
situations as a 'normal' identifier and issue an error if it couldn't but 
otherwise to interpret it as a error handling keyword? 

The error would of course be easy enough to fix but, even if there are no 
other ambiguities, would it just be too confusing and should we simply 
accept that 'check' has to be a 'full' keyword as the design stands? 

Alan
 

-- 
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] interface array and ... operator

[Jan Mercl]

On Wed, Oct 24, 2018 at 7:34 AM Mayank Jha  wrote:

> why does A() not work while B works here,
https://play.golang.org/p/59bpr8TCIge

Type mismatch. The compiler is clear about it:

prog.go:8:12: cannot use s (type []string) as type []interface {}
in append

>From https://golang.org/ref/spec#Appending_and_copying_slices


The variadic function append appends zero or more values x to s of type S,
which must be a slice type,
and returns the resulting slice, also of type S. The values x are passed to
a parameter of type ...T
where T is the element typeof S and the respective parameter passing rules
apply. As a special case,
append also accepts a first argument assignable to type []byte with a
second argument of string type
followed by  This form appends the bytes of the string.
---

In the OP code, type T is `interface{}`, but the appended elements have
type `string`. That violates the above quoted specs.


-- 

-j

-- 
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] Sharing data via Mutex vs. Channel

['Reinhard Luediger' via golang-nuts]

Thanks that sounds reasonable to me

-- 
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] Regarding contracts

[gary . willoughby]

Maybe it's worth adding to: 
https://github.com/golang/go/wiki/Go2GenericsFeedback

On Tuesday, 23 October 2018 17:37:40 UTC+1, Burak Serdar wrote:
>
> I typed this up in a more organized way, and it turned out to be an 
> alternative declaration for contracts without touching the generics 
> parts of the proposal. 
>
> https://gist.github.com/bserdar/8f583d6e8df2bbec145912b66a8874b3 
>

-- 
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: do you use binary-only packages?

[fgergo]

On 10/19/18, Ian Lance Taylor  wrote:
> On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer 
> wrote:
>>
>> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor
>> wrote:
>>>
>>> The question is: is anybody actually doing this?  Is anybody seriously
>>> thinking about it?
>>
>> Unhelpfully, I imagine it unlikely that anyone distributing binary go
>> packages reads golang-dev or golang-nuts.
>
> Is there a more likely place to reach such people?
>
> Ian
>
If you plan to change during the next release maybe there is no better
place, although if the planned timeframe is 2-4 releases in the future
- maybe revisiting the "no warning" policy and a warning on planned
deprecation would be appropriate

-- 
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: do you use binary-only packages?

[fgergo]

On 10/19/18, Ian Lance Taylor  wrote:
> On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer 
> wrote:
>>
>> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor
>> wrote:
>>>
>>> The question is: is anybody actually doing this?  Is anybody seriously
>>> thinking about it?
>>
>> Unhelpfully, I imagine it unlikely that anyone distributing binary go
>> packages reads golang-dev or golang-nuts.
>
> Is there a more likely place to reach such people?
>
> Ian
>
If you plan to change during the next release maybe there is no better
place, although if the planned timeframe is 2-4 releases in the future
- maybe revisiting the "no warning" policy and a warning on planned
deprecation would be appropriate

-- 
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.