[go-nuts] Re: Go 1.9.2 and Go 1.8.5 are released

[Nathan Kerr]

I updated my release related resources:

   - Go Release Timeline 
   - When Should You Upgrade Go? 
   
   
Nathan

On Thursday, October 26, 2017 at 1:52:13 AM UTC+2, Chris Broadfoot wrote:
>
> Hi gophers,
>
> We have just released Go versions 1.9.2 and 1.8.5, minor point releases.
>
> These releases include fixes to the compiler, linker, runtime, 
> documentation, go command, and the crypto/x509, database/sql, log, and 
> net/smtp packages. They include a fix to a bug introduced in Go 1.9.1 and 
> Go 1.8.4 that broke "go get" of non-Git repositories under certain 
> conditions.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.9.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with "git 
> checkout go1.9.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> Chris
>

-- 
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: [golang-dev] Subject: Go 1.9.2 and Go 1.8.5 are released

[Michael Hudson-Doyle]

I've updated my snaps with both these releases, so users with the snap
already installed should get them soon, or snap install --classic --channel
1.9/stable go on an ubuntu or ubuntu-like system if you want to try them
out :)

Cheers,
mwh

On 26 October 2017 at 12:51, Chris Broadfoot  wrote:

> Hi gophers,
>
> We have just released Go versions 1.9.2 and 1.8.5, minor point releases.
>
> These releases include fixes to the compiler, linker, runtime,
> documentation, go command, and the crypto/x509, database/sql, log, and
> net/smtp packages. They include a fix to a bug introduced in Go 1.9.1 and
> Go 1.8.4 that broke "go get" of non-Git repositories under certain
> conditions.
>
> View the release notes for more information:
> https://golang.org/doc/devel/release.html#go1.9.minor
>
> You can download binary and source distributions from the Go web site:
> https://golang.org/dl/
>
> To compile from source using a Git clone, update to the release with "git
> checkout go1.9.2" and build as usual.
>
> Thanks to everyone who contributed to the release.
>
> Chris
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+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] Memory leak when calling highly parallel goroutines

[Michael Jones]

Rob, perhaps it is not clear to you that what you describe is not a memory
leak. Imagine this:

Rob to car wash robot: "Robot, Wash each car in the parking lot, one after
another"
Robot #1: OK

Rob to parking lot robot: "Robot, Park a million cars in the parking lot"
Robot #2: OK.

Rob: "OMG! We have a 1000 acre parking lot! We have a parking lot leak!
Robot #2: We needed a bigger parking lot.

:-)

When you make stuff faster than it gets consumed, you're forcing the
allocation of more parking lot.



On Wed, Oct 25, 2017 at 12:05 PM, Tamás Gulácsi 
wrote:

> Just blind shots:
> resp.Body.Close(),
> sync.Pool the buffers,
> Limit concurrency - the simplest is a make(chan struct{}, 512) ans
> push/pull empry tokens to it.
>
> --
> 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. Jones
michael.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.

[go-nuts] Subject: Go 1.9.2 and Go 1.8.5 are released

[Chris Broadfoot]

Hi gophers,

We have just released Go versions 1.9.2 and 1.8.5, minor point releases.

These releases include fixes to the compiler, linker, runtime,
documentation, go command, and the crypto/x509, database/sql, log, and
net/smtp packages. They include a fix to a bug introduced in Go 1.9.1 and
Go 1.8.4 that broke "go get" of non-Git repositories under certain
conditions.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.9.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with "git
checkout go1.9.2" and build as usual.

Thanks to everyone who contributed to the release.

Chris

-- 
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 misfeature?

[T L]

On Wednesday, October 25, 2017 at 4:51:08 AM UTC-4, Harald Fuchs wrote:
>
> I got bitten by what I'd say is a misfeature in Go: 
>
>   type T1 struct { 
> T2 
> T3 
>   } 
>
>   type T2 struct { 
> T4 
>   } 
>
>   type T3 struct { 
> foo int 
>   } 
>
>   type T4 struct { 
> foo int 
>   } 
>
>   func main() { 
> t1 := T1{ 
>   T2{ 
> T4{ 
>   1, 
> }, 
>   }, 
>   T3{ 
> 2, 
>   }, 
> } 
> fmt.Printf("foo=%d\n", t1.foo) 
>   } 
>
> This prints "foo=2" which surprised me because I was unaware that T1 
> had got another foo via T3 (with less composition depth). 
>
> If I put T4 directly into T1, Go would detect the ambiguity of t1.foo 
> (because the composition depth is the same). 
>
>
The full selector path of T4.foo for T1 is T1.T2.T4.foo,
The full selector path of T3.foo for T1 is T1.T3.foo.
The shortest one will suppress the longer one.
If there are more than two shortest ones, then they collide, none of them 
will be promoted.
 

-- 
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] Memory leak when calling highly parallel goroutines

[Tamás Gulácsi]

Just blind shots:
resp.Body.Close(),
sync.Pool the buffers,
Limit concurrency - the simplest is a make(chan struct{}, 512) ans push/pull 
empry tokens to it.

-- 
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: Is there a workflow engine written in GO

[Samuel Lampa]

You might want to check out http://scipipe.org

We developed it and are currently using it to run cheminformatics pipelines 
(data mangling, machine learning etc) on a HPC cluster, at http://pharmb.io  
at Uppsala University.

Cheers
// Samuel 

On Friday, May 8, 2015 at 2:30:20 PM UTC+2, Sriram Jagadeesan wrote:
>
> I am trying to automated tasks( mainly server task with command line 
> process).
> I am looking for workflow engine if anything written in GOlang, which 
> could be used ?.
> There were some BPM workflow engines, but not suited for command line 
> server operations.
>
> Any input is high appreciated
>
> /Sriram.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] Memory leak when calling highly parallel goroutines

['Rob Archibald' via golang-nuts]

Thanks for your help on this! I really appreciate it. I've been pulling my hair 
out for weeks on this issue, so I truly appreciate any help you can offer.

The way this runs in my production app is similar to how it works in the 
example app I provided. A request is sent to a web server and then up to 1000+ 
http requests are made. Data is pulled, parsed, and ultimately added to a 
database. Each of those requests are done in goroutines and each request 
finishes. But, the memory is never cleaned up. That's why I created this the 
way that I did. I'm aware that if the goroutines never finish or if I create 
them forever, it'll grow infinitely, but that's not what I'm doing. Requests 
come in and are processed and completed, but they're never cleaned up.

As I just mentioned in the Github issue you referenced, it looks like this 
example isn't actually breaking in Linux after all so I'll put together one 
that does break on Linux too. 

Blessings,
Rob Archibald
CTO, EndFirst LLC
r...@robarchibald.com


-Original Message-
From: Ian Lance Taylor [mailto:i...@golang.org] 
Sent: Wednesday, October 25, 2017 11:03 AM
To: Rob Archibald
Cc: golang-nuts
Subject: Re: [go-nuts] Memory leak when calling highly parallel goroutines

On Wed, Oct 25, 2017 at 10:21 AM, Rob Archibald  wrote:
>
> It is a memory leak because the memory continues to grow for as long 
> as the loop continues to run. If you change the code example I gave to 
> an infinite loop you'll see that it grows infinitely. I had it stop at 
> 1000 for demonstration purposes because each scan request that my 
> production app gets typically kicks off about 1000 goroutines.
>
> I posted to the issue you linked to as well. Thanks for letting me 
> know about that.
>
> I'm measuring memory from the system perspective. Windows and Linux 
> both report gigs of memory used on my production app before it crashes 
> due to out of memory. This is a show-stopper issue for me. If Go can't 
> release memory from a simple goroutine when it exits, I'll have to 
> rewrite using something else.

Sorry, I didn't mean to suggest that you should add your program to that issue. 
 I only meant to point to that issue as describing a known problem with 
programs that start a very large number of goroutines and then go back to just 
using a small number of goroutines.  If your program continues to use an 
increasing amount of memory over time, then it is a different problem.

When you say "measuring memory from the system perspective," what precisely do 
you mean?  It really matters, as different system measurements report different 
things, and none of them really correspond to how Go manages its heap.  Or, to 
put it another way, what is the real problem?

I tried running your program.  For me the virtual memory size as measured by 
the ps program goes up to 42176 (42M) and then stops.
This is on GNU/Linux, though, not Windows.

You say that you are describing a memory leak because memory continues to grow 
for as long as the loop continues to run.  Since the loop is starting new 
goroutines more quickly than they can finish, that is not surprising.  If you 
want to control memory usage with a loop like that, you need to limit the 
number of goroutines you start in parallel.

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] Memory leak when calling highly parallel goroutines

[Ian Lance Taylor]

On Wed, Oct 25, 2017 at 10:21 AM, Rob Archibald  wrote:
>
> It is a memory leak because the memory continues to grow for as long as the
> loop continues to run. If you change the code example I gave to an infinite
> loop you'll see that it grows infinitely. I had it stop at 1000 for
> demonstration purposes because each scan request that my production app gets
> typically kicks off about 1000 goroutines.
>
> I posted to the issue you linked to as well. Thanks for letting me know
> about that.
>
> I'm measuring memory from the system perspective. Windows and Linux both
> report gigs of memory used on my production app before it crashes due to out
> of memory. This is a show-stopper issue for me. If Go can't release memory
> from a simple goroutine when it exits, I'll have to rewrite using something
> else.

Sorry, I didn't mean to suggest that you should add your program to
that issue.  I only meant to point to that issue as describing a known
problem with programs that start a very large number of goroutines and
then go back to just using a small number of goroutines.  If your
program continues to use an increasing amount of memory over time,
then it is a different problem.

When you say "measuring memory from the system perspective," what
precisely do you mean?  It really matters, as different system
measurements report different things, and none of them really
correspond to how Go manages its heap.  Or, to put it another way,
what is the real problem?

I tried running your program.  For me the virtual memory size as
measured by the ps program goes up to 42176 (42M) and then stops.
This is on GNU/Linux, though, not Windows.

You say that you are describing a memory leak because memory continues
to grow for as long as the loop continues to run.  Since the loop is
starting new goroutines more quickly than they can finish, that is not
surprising.  If you want to control memory usage with a loop like
that, you need to limit the number of goroutines you start in
parallel.

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] Memory leak when calling highly parallel goroutines

['Rob Archibald' via golang-nuts]

Thanks Ian,
It is a memory leak because the memory continues to grow for as long as the 
loop continues to run. If you change the code example I gave to an infinite 
loop you'll see that it grows infinitely. I had it stop at 1000 for 
demonstration purposes because each scan request that my production app gets 
typically kicks off about 1000 goroutines. 

I posted to the issue you linked to as well. Thanks for letting me know about 
that. 

I'm measuring memory from the system perspective. Windows and Linux both report 
gigs of memory used on my production app before it crashes due to out of 
memory. This is a show-stopper issue for me. If Go can't release memory from a 
simple goroutine when it exits, I'll have to rewrite using something else. 

Blessings,
Rob Archibald
CTO, EndFirst LLC
r...@robarchibald.com

> On Oct 25, 2017, at 6:50 AM, Ian Lance Taylor  wrote:
> 
>> On Wed, Oct 25, 2017 at 12:06 AM,   wrote:
>> 
>> I've got a nasty memory leak. It appears that Go won't reclaim memory when
>> goroutines are called in a highly parallel fashion.
>> 
>> To illustrate the issue I've written a simple example below. When I run this
>> on my Windows system, I get 800MB to 1 GB of memory consumption.
> 
> How are you measuring memory consumption?
> 
> A memory leak implies that memory continues growing without bound.
> That is not what you seem to be reporting.  What you are reporting is
> high memory usage in a steady state.  It's certainly true that if you
> create a large number of goroutines in parallel your program will need
> a bunch of memory to support those goroutines.  And once a program
> requires a large amount of memory, it will hold on to that memory for
> a while, on the assumption that it is likely to happen again.  Over
> time unneeded memory will be released back to the system, where "over
> time" means several minutes.
> 
> That said, there is a current issue: the G structure that represents a
> goroutine is never released.  So if your program starts a large number
> of goroutines at one time, and then never does that again, you will be
> left with some memory that is never released.  This is
> https://golang.org/issue/9869.
> 
> 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] Re: awesome-go project on golang github organization

[Tyler Compton]

It may not be a good idea to put the burden of awesome-go on the Go team,
since it's been pointed out in the past that they don't have extra cycles.
I suspect that's still the case.

On Tue, Oct 24, 2017 at 4:08 PM Dan Kortschak 
wrote:

> I have similar sentiments.
>
> On Tue, 2017-10-24 at 09:19 -0700, prades.m...@gmail.com wrote:
> > I submitted several original projects i made to your list, they
> > passed all
> > the tests, they sat in the pull-request list for 6 month then when
> > rejected
> > for disingenuous or unspecified reasons.So I would prefer not your
> > list
> > becomes the official one.
> >
>
> --
> 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] Multiple Goroutine timeout

[desaiabhijit]

Thanks for the reply

How to gather all the values into CH and return to print

Thanks 

On Wednesday, October 25, 2017 at 7:41:34 PM UTC+5:30, M. Shulhan wrote:
>
> On Wed, 25 Oct 2017 06:30:09 -0700 (PDT) 
> desaia...@gmail.com  wrote: 
>
> > I am expecting to show url1 (2 sec ), url2 (4 sec ) but not url3( 6 
> > sec) where timeout is 5 sec 
> > 
> > but program showing only url1 value 
> > 
> > Please help 
> > 
> > https://play.golang.org/p/aMOoSEHjmZ 
> > 
> > Thanks in advance 
> > 
> > Rgds, 
> > 
> > Abhi 
> > 
> > 
> > package main 
> > 
> > import "fmt" 
> > import "time" 
> > 
> > func InvokeUrl1(u string, val chan<- string) { 
> > time.Sleep(2 * time.Second) 
> > val <- "Url1 Value" 
> > } 
> > func InvokeUrl2(u string, val chan<- string) { 
> > time.Sleep(4 * time.Second) 
> > val <- "Url2 Value" 
> > } 
> > func InvokeUrl3(u string, val chan<- string) { 
> > time.Sleep(6 * time.Second) 
> > val <- "Url3 Value" 
> > } 
> > 
> > func GetUrlValues(urls []string) { 
> > 
> > ch := make(chan string, 1) 
> > for _, url := range urls { 
> > go func(u string) { 
> > val := make(chan string) 
> > if u == "url1" { 
> >   go InvokeUrl1(u, val) 
> > } else if u == "url2" { 
> >   go InvokeUrl2(u, val) 
> > } else if u == "url3" { 
> >   go InvokeUrl3(u, val) 
> > } 
> > 
> > select { 
> > case ret := <-val: 
> > ch <- ret 
> > case <-time.After(5 * time.Second): 
> > ch <- "nil" 
> > } 
> > }(url) 
> > } 
> > fmt.Println(<-ch) 
>
> You only print once, it suppose to be inside the loop or wrapped with 
> select while <-ch != "nil". 
>
> > } 
> > func main() { 
> >   GetUrlValues([]string{"url1", "url2", "url3"}) 
> > } 
> > 
>
>
>
> -- 
> { "name":"Mhd Sulhan", "phone":"+628567826625", "site":"kilabit.info" } 
>

-- 
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] import a "main" package

[Ian Lance Taylor]

On Tue, Oct 24, 2017 at 10:02 PM, Alex Buchanan  wrote:
> Interesting, thanks. Let me try to clarify my idea with some simple code:
>
> // file lives at github.com/buchanae/foobar/foobar.go
> package foobar
>
> func Foobar() string {
>   return "foobar"
> }
>
> func main() {
>   print(Foobar())
> }
>
> This file exports both a function to be used as a library, and a main 
> function which would be compiled into a command line utility. In order to use 
> the library, you'd write `import "github.com/buchanae/foobar"; 
> foobar.Foobar()`. In order to use the command line tool, you'd run `go get 
> github.com/buchanae/foobar` and run `foobar` on the command line. There's no 
> `import "main"` or package named main in this example. The compiler would 
> need to look for a main function in the starting package and perhaps name 
> symbols using the fully qualified package name. Also, packages in the 
> "foobar" tree would not be importing the root, so there are no import cycles.
>
> I'm not sure it's a good idea, but it was my instinct when I started writing 
> Go, and feels like it would have simplified the organization and 
> documentation of some projects which have a separate "go get " for the 
> library vs the CLI command.

Personally I think it's better to separate the library and the
command.  That is particularly true if the command takes any flags.

> Hope that made sense. Probably too late to be writing about such things :)

Indeed.  It's an interesitng idea but this isn't something that is
going to change at this point.

Ian


> On 10/24/17, 9:31 PM, "Ian Lance Taylor"  wrote:
>
>>On Tue, Oct 24, 2017 at 8:14 PM, Alex Buchanan  
>>wrote:
>>>
>>> Is there documentation (or other) explaining why the main package must have
>>> name "main" and may not be imported? Is this an important simplification for
>>> the compiler?
>>
>>The language spec says that the main package must have the name main.
>>I guess we could use other mechanisms but that one seems reasonable to
>>me.
>>
>>cmd/compile prohibiting `import "main"` is a moderately important
>>simplification because cmd/compile uses the import path to set symbol
>>names, and for the main package it uses "main".  If cmd/compile
>>permitted `import "main"` then there would be two different packages
>>with the same import path, which can't work.  So it would have to use
>>something else for the imported "main", but what?
>>
>>Note that cmd/compile does not prohibit importing a package named
>>"main" if the path used to import that package is not specifically
>>"main".  But I think the go tool does prohibit that, and I think that
>>is simply to be less surprising to most people.
>>
>>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] Re: Go misfeature?

[Ian Lance Taylor]

On Wed, Oct 25, 2017 at 7:10 AM, Harald Fuchs  wrote:
> Ian Lance Taylor  writes:
>
>> On Wed, Oct 25, 2017 at 1:43 AM, Harald Fuchs
>>  wrote:
>>>
>>> I got bitten by what I'd say is a misfeature in Go:
>>>
>>>   type T1 struct {
>>> T2
>>> T3
>>>   }
>>>
>>>   type T2 struct {
>>> T4
>>>   }
>>>
>>>   type T3 struct {
>>> foo int
>>>   }
>>>
>>>   type T4 struct {
>>> foo int
>>>   }
>>>
>>>   func main() {
>>> t1 := T1{
>>>   T2{
>>> T4{
>>>   1,
>>> },
>>>   },
>>>   T3{
>>> 2,
>>>   },
>>> }
>>> fmt.Printf("foo=%d\n", t1.foo)
>>>   }
>>>
>>> This prints "foo=2" which surprised me because I was unaware that T1
>>> had got another foo via T3 (with less composition depth).
>>>
>>> If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
>>> (because the composition depth is the same).
>>
>> What is the misfeature, though?  You gave us a clear explanation of
>> what you did and what happened; thanks very  much for doing that.  But
>> you didn't say what you expected to happen instead.
>>
>> I'll speculate that perhaps you would prefer a compilation error due
>> to an ambiguous field.
>
> Yes, that's what I would have expected (sorry for not mentioning it).
>
>> Not doing that was an explicit decision.
>> Consider a struct in package P1 that embeds two structs, one from
>> package P2 and one from P3.  Suppose the struct in P3 embeds another
>> struct from P4.  Suppose that all four packages are in different
>> github repos maintained by different people; recall that one of the
>> explicit goals of the Go language is to support programming at scale.
>> With this organization, package P1 can refer directly to fields
>> defined in P2 and P3.  We want it to be possible for P4 to add a
>> field, a field that might happen to duplicate a field in P2--in this
>> example, P2 and P4 might not even know about each other at all--and we
>> want that to happen without breaking P1.  Hope that makes sense.
>
> For us, it *did* break P1 in the sense that this silently changing its
> semantics.  And how about the following?
>
>   type P1 struct {
> P2
> P3
>   }
>
>   type P2 struct {
> P4
>   }
>
>   type P3 struct {
> P5
>   }
>
>   type P4 struct {
> foo int
>   }
>
>   type P5 struct {
> // foo int
>   }
>
> P2 and P3 don't know each other.  P1 breaks if P5 gets another foo.
> It's almost the same (except composition depth), isn't it?

Yes.  You are only safe from changes deeper in the type hierarchy if
you only reference fields defined without embedding in the types that
you embed directly.

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: [ANN] Cross-platform HTML/CSS GUI library

[Serge Zaitsev]

Thanks for the feedback!

You know when the app is terminated because that's when the main loop ends 
(e.g. Loop() returns false, or Run() just returns). So you can write any 
code after webview.Run() and it will be executed when user presses close 
button.

App icon is something on my list. Currently, app icon can be set on Windows 
and Mac without any code (using .rc file or app bundle .icns file).
I also plan to make a function to set window icon for Gtk and Windows in 
runtime. So yes, it's definitely a high-priority. Webview apps should look 
like normal apps for the end user.

Menus on the other hand is definitely something important to have, but it 
is likely to bring a lot of code for all three platforms, and the API is 
likely to get more complex.
I think one day I will add that, too, but at the moment I can't promise 
much. Hopefully, tray menu can also be implemented by reusing most of the 
code.

On Wednesday, October 25, 2017 at 4:51:37 PM UTC+3, Ain wrote:
>
>
> On Wednesday, October 25, 2017 at 3:39:42 PM UTC+3, Serge Zaitsev wrote:
>>
>> Hey all,
>>
>> I made a tiny library that provides a cross-platform web UI for Go apps.
>>
>> https://github.com/zserge/webview
>>
>
> Looks intresting, thanks for making it available!
>  
>  
>
>>  
>>
> Apart from the app architecture, I wonder what features do you think this 
>> library lacks for your needs, or what could be done better.
>> Any ideas, feedback or critique are welcome.
>>
>
> Of the top of my head:
>  - callback when app is terminated (via the [x] button on titlebar);
>  - ability to create native menu for the main wnd;
>  - ability to set app icon.
>
>
> ain
>

-- 
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 misfeature?

[Harald Fuchs]

Ian Lance Taylor  writes:

> On Wed, Oct 25, 2017 at 1:43 AM, Harald Fuchs
>  wrote:
>>
>> I got bitten by what I'd say is a misfeature in Go:
>>
>>   type T1 struct {
>> T2
>> T3
>>   }
>>
>>   type T2 struct {
>> T4
>>   }
>>
>>   type T3 struct {
>> foo int
>>   }
>>
>>   type T4 struct {
>> foo int
>>   }
>>
>>   func main() {
>> t1 := T1{
>>   T2{
>> T4{
>>   1,
>> },
>>   },
>>   T3{
>> 2,
>>   },
>> }
>> fmt.Printf("foo=%d\n", t1.foo)
>>   }
>>
>> This prints "foo=2" which surprised me because I was unaware that T1
>> had got another foo via T3 (with less composition depth).
>>
>> If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
>> (because the composition depth is the same).
>
> What is the misfeature, though?  You gave us a clear explanation of
> what you did and what happened; thanks very  much for doing that.  But
> you didn't say what you expected to happen instead.
>
> I'll speculate that perhaps you would prefer a compilation error due
> to an ambiguous field.

Yes, that's what I would have expected (sorry for not mentioning it).

> Not doing that was an explicit decision.
> Consider a struct in package P1 that embeds two structs, one from
> package P2 and one from P3.  Suppose the struct in P3 embeds another
> struct from P4.  Suppose that all four packages are in different
> github repos maintained by different people; recall that one of the
> explicit goals of the Go language is to support programming at scale.
> With this organization, package P1 can refer directly to fields
> defined in P2 and P3.  We want it to be possible for P4 to add a
> field, a field that might happen to duplicate a field in P2--in this
> example, P2 and P4 might not even know about each other at all--and we
> want that to happen without breaking P1.  Hope that makes sense.

For us, it *did* break P1 in the sense that this silently changing its
semantics.  And how about the following?

  type P1 struct {
P2
P3
  }

  type P2 struct {
P4
  }

  type P3 struct {
P5
  }

  type P4 struct {
foo int
  }

  type P5 struct {
// foo int
  }

P2 and P3 don't know each other.  P1 breaks if P5 gets another foo.
It's almost the same (except composition depth), isn't it?

-- 
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] Multiple Goroutine timeout

[Shulhan]

On Wed, 25 Oct 2017 06:30:09 -0700 (PDT)
desaiabhi...@gmail.com wrote:

> I am expecting to show url1 (2 sec ), url2 (4 sec ) but not url3( 6
> sec) where timeout is 5 sec
> 
> but program showing only url1 value
> 
> Please help
> 
> https://play.golang.org/p/aMOoSEHjmZ
> 
> Thanks in advance
> 
> Rgds,
> 
> Abhi
> 
> 
> package main
> 
> import "fmt"
> import "time"
> 
> func InvokeUrl1(u string, val chan<- string) {
> time.Sleep(2 * time.Second)
> val <- "Url1 Value"
> }
> func InvokeUrl2(u string, val chan<- string) {
> time.Sleep(4 * time.Second)
> val <- "Url2 Value"
> }
> func InvokeUrl3(u string, val chan<- string) {
> time.Sleep(6 * time.Second)
> val <- "Url3 Value"
> }
> 
> func GetUrlValues(urls []string) {
> 
> ch := make(chan string, 1)
> for _, url := range urls {
> go func(u string) {
> val := make(chan string)
> if u == "url1" {
>   go InvokeUrl1(u, val)
> } else if u == "url2" {
>   go InvokeUrl2(u, val)
> } else if u == "url3" {
>   go InvokeUrl3(u, val)
> }
> 
> select {
> case ret := <-val:
> ch <- ret
> case <-time.After(5 * time.Second):
> ch <- "nil"
> }
> }(url)
> }
> fmt.Println(<-ch)

You only print once, it suppose to be inside the loop or wrapped with
select while <-ch != "nil".

> }
> func main() {
>   GetUrlValues([]string{"url1", "url2", "url3"})
> }
> 



-- 
{ "name":"Mhd Sulhan", "phone":"+628567826625", "site":"kilabit.info" }

-- 
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] Multiple Goroutine timeout

[Ian Lance Taylor]

As far as I can see your GetUrlValues function only ever prints one string.

Ian

On Wed, Oct 25, 2017 at 6:30 AM,   wrote:
> I am expecting to show url1 (2 sec ), url2 (4 sec ) but not url3( 6 sec)
> where timeout is 5 sec
>
> but program showing only url1 value
>
> Please help
>
> https://play.golang.org/p/aMOoSEHjmZ
>
> Thanks in advance
>
> Rgds,
>
> Abhi
>
>
> package main
>
> import "fmt"
> import "time"
>
> func InvokeUrl1(u string, val chan<- string) {
> time.Sleep(2 * time.Second)
> val <- "Url1 Value"
> }
> func InvokeUrl2(u string, val chan<- string) {
> time.Sleep(4 * time.Second)
> val <- "Url2 Value"
> }
> func InvokeUrl3(u string, val chan<- string) {
> time.Sleep(6 * time.Second)
> val <- "Url3 Value"
> }
>
> func GetUrlValues(urls []string) {
>
> ch := make(chan string, 1)
> for _, url := range urls {
> go func(u string) {
> val := make(chan string)
> if u == "url1" {
>   go InvokeUrl1(u, val)
> } else if u == "url2" {
>   go InvokeUrl2(u, val)
> } else if u == "url3" {
>   go InvokeUrl3(u, val)
> }
>
> select {
> case ret := <-val:
> ch <- ret
> case <-time.After(5 * time.Second):
> ch <- "nil"
> }
> }(url)
> }
> fmt.Println(<-ch)
> }
> func main() {
>   GetUrlValues([]string{"url1", "url2", "url3"})
> }
>
> --
> 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] Re: [ANN] Cross-platform HTML/CSS GUI library

[Ain]

On Wednesday, October 25, 2017 at 3:39:42 PM UTC+3, Serge Zaitsev wrote:
>
> Hey all,
>
> I made a tiny library that provides a cross-platform web UI for Go apps.
>
> https://github.com/zserge/webview
>

Looks intresting, thanks for making it available!
 
 

>  
>
Apart from the app architecture, I wonder what features do you think this 
> library lacks for your needs, or what could be done better.
> Any ideas, feedback or critique are welcome.
>

Of the top of my head:
 - callback when app is terminated (via the [x] button on titlebar);
 - ability to create native menu for the main wnd;
 - ability to set app icon.


ain

-- 
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] Memory leak when calling highly parallel goroutines

[Ian Lance Taylor]

On Wed, Oct 25, 2017 at 12:06 AM,   wrote:
>
> I've got a nasty memory leak. It appears that Go won't reclaim memory when
> goroutines are called in a highly parallel fashion.
>
> To illustrate the issue I've written a simple example below. When I run this
> on my Windows system, I get 800MB to 1 GB of memory consumption.

How are you measuring memory consumption?

A memory leak implies that memory continues growing without bound.
That is not what you seem to be reporting.  What you are reporting is
high memory usage in a steady state.  It's certainly true that if you
create a large number of goroutines in parallel your program will need
a bunch of memory to support those goroutines.  And once a program
requires a large amount of memory, it will hold on to that memory for
a while, on the assumption that it is likely to happen again.  Over
time unneeded memory will be released back to the system, where "over
time" means several minutes.

That said, there is a current issue: the G structure that represents a
goroutine is never released.  So if your program starts a large number
of goroutines at one time, and then never does that again, you will be
left with some memory that is never released.  This is
https://golang.org/issue/9869.

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 misfeature?

[Ian Lance Taylor]

On Wed, Oct 25, 2017 at 1:43 AM, Harald Fuchs  wrote:
>
> I got bitten by what I'd say is a misfeature in Go:
>
>   type T1 struct {
> T2
> T3
>   }
>
>   type T2 struct {
> T4
>   }
>
>   type T3 struct {
> foo int
>   }
>
>   type T4 struct {
> foo int
>   }
>
>   func main() {
> t1 := T1{
>   T2{
> T4{
>   1,
> },
>   },
>   T3{
> 2,
>   },
> }
> fmt.Printf("foo=%d\n", t1.foo)
>   }
>
> This prints "foo=2" which surprised me because I was unaware that T1
> had got another foo via T3 (with less composition depth).
>
> If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
> (because the composition depth is the same).

What is the misfeature, though?  You gave us a clear explanation of
what you did and what happened; thanks very  much for doing that.  But
you didn't say what you expected to happen instead.

I'll speculate that perhaps you would prefer a compilation error due
to an ambiguous field.  Not doing that was an explicit decision.
Consider a struct in package P1 that embeds two structs, one from
package P2 and one from P3.  Suppose the struct in P3 embeds another
struct from P4.  Suppose that all four packages are in different
github repos maintained by different people; recall that one of the
explicit goals of the Go language is to support programming at scale.
With this organization, package P1 can refer directly to fields
defined in P2 and P3.  We want it to be possible for P4 to add a
field, a field that might happen to duplicate a field in P2--in this
example, P2 and P4 might not even know about each other at all--and we
want that to happen without breaking P1.  Hope that makes sense.

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] Multiple Goroutine timeout

[desaiabhijit]

I am expecting to show url1 (2 sec ), url2 (4 sec ) but not url3( 6 sec) 
where timeout is 5 sec

but program showing only url1 value

Please help

https://play.golang.org/p/aMOoSEHjmZ

Thanks in advance

Rgds,

Abhi


package main

import "fmt"
import "time"

func InvokeUrl1(u string, val chan<- string) {
time.Sleep(2 * time.Second)
val <- "Url1 Value"
}
func InvokeUrl2(u string, val chan<- string) {
time.Sleep(4 * time.Second)
val <- "Url2 Value"
}
func InvokeUrl3(u string, val chan<- string) {
time.Sleep(6 * time.Second)
val <- "Url3 Value"
}

func GetUrlValues(urls []string) {

ch := make(chan string, 1)
for _, url := range urls {
go func(u string) {
val := make(chan string)
if u == "url1" {
  go InvokeUrl1(u, val)
} else if u == "url2" {
  go InvokeUrl2(u, val)
} else if u == "url3" {
  go InvokeUrl3(u, val)
}

select {
case ret := <-val:
ch <- ret
case <-time.After(5 * time.Second):
ch <- "nil"
}
}(url)
}
fmt.Println(<-ch)
}
func main() {
  GetUrlValues([]string{"url1", "url2", "url3"})
}

-- 
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] [ANN] Cross-platform HTML/CSS GUI library

[Serge Zaitsev]

Hey all,

I made a tiny library that provides a cross-platform web UI for Go apps.

https://github.com/zserge/webview

No dependencies on Windows and Mac. Gtk-Webkit is only required on Linux 
and OpenBSD.
Resulting binaries are much smaller and less resource-hungry comparing to 
Electron.
Supported browser engines are modern enough to let developers use 
HTML5/CSS3 without any quirks (on Windows IE10-IE11 are used).

I tried to keep Go API very simple, and the whole library is very concise, 
too.

JavaScript<->Go bindings are provided to let core app communicate with the 
UI.

I haven't thought much about how to architect such apps, but to me the 
reactive approach works really well (something similar to redux). I keep 
app state in Go as a structure, pass it as JSON to the UI and incrementally 
update the UI (using picodom.js).
Also, in response to UI actions I send a JSON describing the action and its 
parameters to Go where I handle it and update the state.
You may look at an example 
here: https://github.com/zserge/webview/tree/master/examples/todo-go

Apart from the app architecture, I wonder what features do you think this 
library lacks for your needs, or what could be done better.
Any ideas, feedback or critique are welcome.

Thanks!
Serge

-- 
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] edit configuration:cannot find go file with main in package 'gods-master/examples'

[starliao2017]

I want to run a programme,so I set the edit configuration but catch a 
error:cannot find go file with main in package 'gods-master/examples'.
so how to slove this problem?

-- 
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 misfeature?

['Axel Wagner' via golang-nuts]

On Wed, Oct 25, 2017 at 11:02 AM, Lutz Horn  wrote:

> This prints "foo=2" which surprised me because I was unaware that T1
>> had got another foo via T3 (with less composition depth).
>>
>> If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
>> (because the composition depth is the same).
>>
>
> There is no ambiguity because `T4.foo` is not promoted to a field of `T1`.


Yes, it is
https://play.golang.org/p/hm3OpPBsex

`T4.foo` *is* a promoted field of `T2` but promotion is not transitive.
>
> see https://play.golang.org/p/GFgJGTSGGd
>
> Read about this on:
>
> *  https://golang.org/ref/spec#Struct_types
> * https://golang.org/ref/spec#Selectors
>
> Lutz
>
>
> --
> 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 misfeature?

[Lutz Horn]

This prints "foo=2" which surprised me because I was unaware that T1
had got another foo via T3 (with less composition depth).

If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
(because the composition depth is the same).


There is no ambiguity because `T4.foo` is not promoted to a field of 
`T1`. `T4.foo` *is* a promoted field of `T2` but promotion is not 
transitive.


see https://play.golang.org/p/GFgJGTSGGd

Read about this on:

*  https://golang.org/ref/spec#Struct_types
* https://golang.org/ref/spec#Selectors

Lutz

--
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: A tour of go - Since a couple days ago the line numbers started to render on the right side or the margin line (instead of left).

[jra]

I see that as well with Chrome and Firefox.

When I used the instructions 

 
to run a local copy of the tour to debug it, the problem went away.

So it has something to do with how it is run/served from golang.org.

 -jeff

-- 
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 misfeature?

[Harald Fuchs]

I got bitten by what I'd say is a misfeature in Go:

  type T1 struct {
T2
T3
  }

  type T2 struct {
T4
  }

  type T3 struct {
foo int
  }

  type T4 struct {
foo int
  }

  func main() {
t1 := T1{
  T2{
T4{
  1,
},
  },
  T3{
2,
  },
}
fmt.Printf("foo=%d\n", t1.foo)
  }

This prints "foo=2" which surprised me because I was unaware that T1
had got another foo via T3 (with less composition depth).

If I put T4 directly into T1, Go would detect the ambiguity of t1.foo
(because the composition depth is the same).

-- 
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-any: a more generic way to download Go versions

[jra]

If anyone is interested, I have made a tiny update to the tool used to 
download and run release candidates which makes it useful for any version 
number:

  
https://github.com/jeffallen/build/commit/dfeb16f0a5edb0c0c2a8278962812ce100f63bff

I find it useful, you might too. If someone from the Go core team asks me 
to, I will submit it as a CL.

  -jeff

-- 
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] sync.Map performance problem

[Konstantin Khomoutov]

On Fri, Oct 20, 2017 at 11:50:42PM -0700, barce show wrote:

> I use sync.Map in my program to support access concurrently, but witin two 
> hours with less than 50 clients, my program run out all of my cpu, so I go 
> back to read the pkg document, and I find this sentence 
> 
> "For use cases that do not share these attributes, it will likely have 
> comparable or worse performance and worse type safety than an ordinary map 
> paired with a read-write mutex."

You seem to omit the key point from the description [1], which is

| It is optimized for use in concurrent loops with keys that are stable
| over time, and either few steady-state stores, or stores localized to
| one goroutine per key.

I dare to "translate" this into more layman's language in the following
way:

  the sync.Map is optimized for the use cases where the following
  two conditions are met:
  
  1. The keys in the map are mostly stable.  That is, there is no
 constant churn of the keys — insertions and deletions, — but rather
 reads and updates.

  2. There is not much stores (into the same keys, mostly, — see above)
 compared to the number of reads
 - or -
 such stores are performed by the same goroutine, — that is, each
 goroutine updates the data under its own key, and no other
 goroutine does that, or does this infrequently.

>From this, we may gather that the implementation of sync.Map supposedly
uses a couple of tricks which are more involved than just having a
single sync.RWMutex under the hood.  The implementation goes to those
lengths to improve the performance for the cases outlined above but, as
with all things related to optimizations, it sucks performance-wise for
the cases which do not fit into the intended usage pattern.

You can see this even with the simple locks: the sync.RWMutex allows
multiple parattel readers and only goes exclusive for a writer but the
payback is the implementation slower than sync.Mutex which is
all-exclusive, and so if you have roughly equal numbers of readers and
writers sync.RWMutex may actually work slower for your case.

> maybe this the my problem, but I don't really understand what it represent
> can anybody help me?

May I ask whether you have actually profiled your problem?
Are you sure that's sync.Map which affects your performance, and not
something else completely?

Go comes packed with a slew of tools to profile your programs.
You should start with the CPU profile and block profile.
There are lots of information on how to start with profiling the Go code
so just use your favourite search engine to get started.

1. https://golang.org/pkg/sync/#Map

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