Re: [go-nuts] Elphaba Chess

[Filip Zaludek]

https://chessprogramming.wikispaces.com/Alpha-Beta

-- 
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] Combine low traffic website

[Andrew]

Thanks, I'll try Caddy first.

-- 
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] Elphaba Chess

[andrey mirtchovski]

>  FireFox actually uses Yahoo --- not Google --- so if Google did make a
> donation to Mozilla, they got nothing in return.
> You're not supposed to expect something in return when you make a donation
> to a non-profit --- donations are not supposed to be a business deal.

this is highly offtopic, for which i apologize. firefox used google
until 2014, when they started using yahoo. now they're back to using
google and are suing each other with yahoo:

https://blog.mozilla.org/blog/2017/11/14/firefox-features-google-as-default-search-provider-in-the-u-s-canada-hong-kong-and-taiwan/

-- 
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] Elphaba Chess

[hughaguilar96]

On Monday, December 4, 2017 at 10:38:35 AM UTC-7, Hugh Aguilar wrote:
>
>
>
> On Monday, December 4, 2017 at 7:11:09 AM UTC-7, Gerald wrote:
>>
>> On Sun, 3 Dec 2017 20:07:45 -0800 (PST), you wrote: 
>>
>> >I'll bet if Mozilla had used Go to write FireFox, rather than invent 
>> their 
>> >own language, Google would have done something to stop them. 
>>
>> You are aware that Google helps fund Firefox (through their agreement 
>> to be the default search engine)? 
>>
>
> I was not aware of that.
>
> I only recently started using FireFox. Previously I had used Google Chrome.
> My new computer crashed after I installed Chrome and I was suspicious that 
> Chrome caused this. 
> Also, my old computer became very slow and I was suspicious of Chrome 
> being the cause of this.
> Because of these reasons, I switched to FireFox.
>

 FireFox actually uses Yahoo --- not Google --- so if Google did make a 
donation to Mozilla, they got nothing in return.
You're not supposed to expect something in return when you make a donation 
to a non-profit --- donations are not supposed to be a business deal. 

I'm having problems with my new computer. It became so slow that it took 20 
minutes just to boot up. 
I killed the Microsoft Edge browser and left only FireFox running, and it 
seems to be working better.
I don't know if this means Chrome or Edge are necessarily at fault. Maybe 
browsers just use a lot of memory and so only one should be used at a time.
It seems depressing to me that we now have 64-bit dual-core computers 
available for less than a week's wages, 
but our software is so bad that my old Commodore-64 is still faster (for 
simple things like text editing that it could do).

Anyway, all of this has gone way off-topic. Windows has always sucked, and 
it will continue to suck forever --- there is not much more to say on the 
subject.
I will look into those Go chess programs that were mentioned earlier.
I still don't know much about the Alpha-Beta algorithm, so if anybody has 
any further information on that subject I would be interested in reading 
this.

-- 
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: net/http Server Shutdown does not free up the port upon return

[Amnon Baron Cohen]

netstat is your friend

On Wednesday, 29 November 2017 04:53:48 UTC, Albert Tedja wrote:
>
> net/http's Shutdown() does not free up the port upon return, or rather it 
> seems a bit undefined how long it takes for the port to be reusable again.
>
> server := {
> Addr: fmt.Sprintf(":9000"),
> }
> go func() {
> fmt.Println("hosting...")
> err := server.ListenAndServe()
> }()
> time.Sleep(1 * time.Second)
>
> fmt.Println("closing")
> err := server.Shutdown(nil)
> fmt.Println("shutdown error", err)
>
> fmt.Println("hosting again...")
> err = server.ListenAndServe()
> fmt.Println("host again err", err)
>
>
>
> The code above, for example, sometimes successfully hosting the http 
> server twice, but sometimes, the second one fails with "address already in 
> use" error
>
> $ go run main.go 
> hosting...
> closing
> shutdown error 
> hosting again...
> // This is okay
>
> $ go run main.go 
> hosting...
> closing
> shutdown error 
> hosting again...
> host again err listen tcp :9000: bind: address already in use
>
> My question is, is this a bug, or an expected undetermined behavior? If 
> it's the latter, how can I safely make sure that Shutdown() completely 
> frees up the port used?
>
>

-- 
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: Errors with uploading large files (> 1gb) - multipart

[Dave Cheney]

Perhaps calling next part is consuming reader, so when you break at once you 
hit io.EOF, the reader you memorised has been consumed. 

Again, just a guess, I’ve never used the multipart package in anger. 

-- 
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] Why so many opt-out changes to test runs in 1.10?

[Ian Lance Taylor]

On Fri, Dec 8, 2017 at 12:43 PM,   wrote:
>
> In addition to that I think our viewpoints on test caching are different
> because our use cases of Go are different. I come upon this feature not as
> someone who deals with large berths of unchanging Go packages all the time
> (Go and it's standard library, presumably like yourself), but relatively
> small packages that interact with databases. In my use case I don't want my
> tests cached on my primary project as my test bottleneck is not the Go code
> that would be cached, but the database interaction that cannot be cached
> (because of the lack of invalidation at this layer). I understand you'd like
> me to try it, but if there's a provable theoretical problem with it, isn't
> it practical to address it, and isn't switching the default a reasonable way
> to address that?

How does your program interact with your database?

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: Errors with uploading large files (> 1gb) - multipart

[seth cohen]

Dave, thanks for the reply!

That bit is OK... you are correct that it won't break out of the loop until 
io.EOF. It comes across the uploadfile part first and sets the variable 
accordingly. Then once, looped through all parts, it breaks the loop and I 
try to copy the file - wherein I run into the issue.

-Seth

On Friday, December 8, 2017 at 4:07:17 PM UTC-5, Dave Cheney wrote:
>
> I’ve never used the multipart reader, but looking at this piece of logic 
>
> var uploadFile *multipart.Part 
> for { 
> p, err := fr.NextPart() 
> if err == io.EOF { 
> break 
> } 
> if err != nil { 
> log.Fatal(err) 
> } 
> if err != nil { 
> log.Fatal(err) 
> } 
> if p.FormName() == "uploadfile" { 
> uploadFile = p 
> fmt.Println("UploadFile: ", uploadFile) 
> } 
> } 
>
> It seems to me that the loop will only exit when fr.NextPart returns 
> io.EOF ( all other cases will cause your program to exit). The example from 
> godoc has a suggestion for how to process the uploaded file 
> https://golang.org/pkg/mime/multipart/#example_NewReader

-- 
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] Errors with uploading large files (> 1gb) - multipart

[Dave Cheney]

I’ve never used the multipart reader, but looking at this piece of logic

var uploadFile *multipart.Part
for {
p, err := fr.NextPart()
if err == io.EOF {
break
}
if err != nil {
log.Fatal(err)
}
if err != nil {
log.Fatal(err)
}
if p.FormName() == "uploadfile" {
uploadFile = p
fmt.Println("UploadFile: ", uploadFile)
}
}

It seems to me that the loop will only exit when fr.NextPart returns io.EOF ( 
all other cases will cause your program to exit). The example from godoc has a 
suggestion for how to process the uploaded file 
https://golang.org/pkg/mime/multipart/#example_NewReader

-- 
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] Errors with uploading large files (> 1gb) - multipart

[seth . h . cohen]

   
   1. *Go Version*
  - go version go1.6.3 linux/amd64
  2. *OS*
  - CentOS Linux release 7.1.1503 (Core)
  3. *Description of Problem*
  - *GOAL: *Handle files (can be of any arbitrarily large size) on my 
  server and then upload to google cloud storage.
  - With the code below I have no trouble uploading 40+mb files, 
  however, I have a requirement to be able handle an upload file of >2gb.
  - I have tried a number of things and encountered 3 distinct errors. 
  I was initially using the following code to handle the file upload
   4. *I am very new to Go*
   5. *This is my first Groups post ever*

*SERVER - works for smaller files (until I run out of memory)*
func upload(w http.ResponseWriter, r *http.Request) {
// I dunno it'd just be cool to see where we are in our code from the 
server should prolly just delete this
fmt.Println("handling file upload", r.Method)
if r.Method == "POST" {
// debugging only
fmt.Println("We've got a POST")

r.ParseMultipartForm(32 << 20)
file, handler, err := r.FormFile("uploadfile")
if err != nil {
fmt.Println("FormFile: ", err)
return
}

// Meat and potatoes - the only reason this method exists
fileURL, err := storage.UploadFileToBucket(file, handler, bucketID)
if err != nil {
fmt.Println("UploadFileToBucket: ", err)
}

// I think clients would appreciate if we told them that we created 
something
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(map[string]string{"url": fileURL})
} else {
// You can't expect me to create a resource - Do you GET me?
err := fmt.Errorf("Method is not supported, %s\n", r.Method)
fmt.Print(err)

json.NewEncoder(w).Encode(map[string]string{"error": err.Error()})
}
}

Again the above works fine for files even in excess of 40mb however, if I 
attempt to handle a file uploaded of 2gb then I receive a
 no such file

error from the call to 
r.FormFile

I have tried increasing default memory size on `ParseMultipartForm` to 
256mb and same exact symptom.If I increase it to greater than 2gb I get an 
OOM error and connection get's reset. OK, fine - I get that.

Let's pivot!! So I try to use `multiPart.Reader` instead to stream the 
data. This, however, gives me a different error. Regardless of file size, I 
get an 
unexpected EOF
in io.Copy().

*UPDATE SERVER - doesn't work for any size files*
func uploadLarge(w http.ResponseWriter, r *http.Request) {
// I dunno it'd just be cool to see where we are in our code from the 
server should prolly just delete this
fmt.Println("handling large file upload", r.Method)
if r.Method == "POST" {
// debugging only
fmt.Println("We've got a POST")

// we have a huge file so we should try to stream it
mr, err := r.MultipartReader()
if err != nil {
log.Fatal("MultipartReader: ", err)
}
fileURL, err := storage.UploadLargeFile(mr, bucketID)
if err != nil {
fmt.Println("UploadLargeFile: ", err)
}

// I think clients would appreciate if we told them that we created 
something
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(map[string]string{"url": fileURL})
} else {
// You can't expect me to create a resource - Do you GET me?
err := fmt.Errorf("Method is not supported, %s\n", r.Method)
fmt.Print(err)

json.NewEncoder(w).Encode(map[string]string{"error": err.Error()})
}
}

*STORAGE Package - UploadLargeFile*
func UploadLargeFile(fr *multipart.Reader, bucketID string) (url string, 
err error) {
if client == nil {
client = createStorageClient()
}

bucket, ok := buckets[bucketID]
if !ok {
bucket = client.Bucket(bucketID)
buckets[bucketID] = bucket
}

var uploadFile *multipart.Part
for {
p, err := fr.NextPart()
if err == io.EOF {
break
}
if err != nil {
log.Fatal(err)
}
if err != nil {
log.Fatal(err)
}
if p.FormName() == "uploadfile" {
uploadFile = p
fmt.Println("UploadFile: ", uploadFile)
}
}

// Create the object writer and send the file to GCS
ctx := context.Background()
w := bucket.Object(uploadFile.FileName()).NewWriter(ctx)
w.ACL = []storage.ACLRule{{Entity: storage.AllUsers, Role: 
storage.RoleReader}}
w.CacheControl = "public, max-age=86400"

// Copy the file data to the writer
if _, err := io.Copy(w, uploadFile); err != nil {
fmt.Println("Copy: ", err)
return "", err
}
if err := w.Close(); err != nil {
return "", err
}

const publicURL = "https://storage.googleapis.com/%s/%s;
return fmt.Sprintf(publicURL, bucketID, uploadFile.FileName()), 

Re: [go-nuts] Why so many opt-out changes to test runs in 1.10?

[bits128]

I agree on the getting the experience right for Go users piece and I think 
that we both see our views as in line with that theory. I think having less 
surprising, less gotchas and less defaults-gone-wrong behavior is better 
than enabling things that will get in their way and cost them development 
time. Remember the old adage that there are two hard things in programming, 
one of which is cache invalidation. I don't think we can get this correct. 
And so I stand by my point that this as a default will cause more harm than 
good. By the time a user has a sizable enough project (or dependencies) 
where test caching makes sense to use, it's reasonable to expect that they 
are no longer a beginner and that they can learn to use the flag if 
required to save themselves some test-run time. The other good thing about 
this, is we can easily change the default later to on once we figure out 
how good the feature is.

In addition to that I think our viewpoints on test caching are different 
because our use cases of Go are different. I come upon this feature not as 
someone who deals with large berths of unchanging Go packages all the time 
(Go and it's standard library, presumably like yourself), but relatively 
small packages that interact with databases. In my use case I don't want my 
tests cached on my primary project as my test bottleneck is not the Go code 
that would be cached, but the database interaction that cannot be cached 
(because of the lack of invalidation at this layer). I understand you'd 
like me to try it, but if there's a provable theoretical problem with it, 
isn't it practical to address it, and isn't switching the default a 
reasonable way to address that?

In the end I still feel strongly against the inclusion of test caching by 
default, and think it will bring pain to those who are not specifically 
asking for the feature whom are knowledgeable and who can turn it on when 
necessary anyway.

On the go vet issue I'm actually a bit indifferent and no longer wish to 
pursue it's exclusion as a default simply because I don't care about this 
one enough. But I still think you should think on the arguments I've made 
here because it's a very inconsistent position to have taken. To glob on to 
go test's responsibilities but at the same time rejecting the idea that 
these same issues discovered by go vet cause major problems in normally 
compiled code is odd. The major problem with that stance of course is 
allowing one and disallowing the other for the same crimes.

I've made some additional comments inline.

Thanks for taking the time to respond. I've made all my points and don't 
want to waste your time with another response, so I will try these features 
and report the cache invalidation issue with a real use case and real code 
to show why it's a problem.

Thanks very much for Go 1.10 and each release before it, I really enjoy the 
language.

Aaron

On Friday, December 8, 2017 at 11:21:37 AM UTC-8, Russ Cox wrote:
>
> First, a general point.
>
> We care very much about getting the default experience right for Go users. 
> These features are opt-in because we believe in both cases that "on" is the 
> right default, that developers will be more productive with these on by 
> default than having to know to opt in.
>
> - You should also not have to ask for "go test" to point out certainly 
> erroneous code instead of forcing you to find that code by debugging a test 
> failure.
>
>
This conflates the idea of testing the code by running the tests you've 
created, with making sure the code is clean and correct. But this just 
suggests even further that if there are such "certainly erroneous" pieces 
of code, that the compiler should be catching it. If it is necessary for 
the program to run correctly, then it should not be a valid program, the 
inclusion of this feature as a default even demonstrates the need for it.
 

> - You should not have to ask for "go test ./...; modify a few source 
> files; go test ./..." to do the right thing and only rerun the test 
> binaries affected by your changes. 
>
>
Doing the right thing and only rerunning the test binaries affected is not 
always the right thing, just sometimes, cache invalidation as noted above.
 

> A new Go programmer who doesn't know these features exist should get the 
> benefit of these from day 1, without having to learn to set extra 
> configuration (which doesn't actually exist) or type extra arguments on 
> every go test command. Of course, turning them on by default means they 
> have to be right, and we're very sensitive to that. If you find concrete 
> examples where automatic vet or automatic test caching is causing you pain, 
> please file issues so that we can look to see if the defaults need further 
> adjustment. But please give them a chance first, actually try them, and 
> then report concrete problems, not hypotheticals based on simply reading 
> the release notes.
>
> Now a few specifics.
>
> For test caching:
>
> > Or 

Re: [go-nuts] Why so many opt-out changes to test runs in 1.10?

[Jakob Borg]

On 8 Dec 2017, at 20:20, Russ Cox > 
wrote:

For test caching:

For the record, I’ve used 1.10beta1 for all of about ten minutes now and it’s 
already transformed the way I work.

I can now actually run the full test suite locally as part of editing and 
testing, as it takes mere seconds due to the caching. Previously I’d mostly 
just compile and hope, and let the build server run the tests (taking ~ 5 
minutes or so) later as part of a pull request.

This is great.

//jb

-- 
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] GoLang dependency -> dep installation Issue , Burrow golang tool issues

[Ondrej Fabry]

I am not sure what is your problem exactly. Did you follow the readme and 
actually installed dep tool?

-- 
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] Combine low traffic website

[Jakob Borg]

On 8 Dec 2017, at 20:58, Gianguido Sorà 
> wrote:

You could run the two programs on the same vps by binding them to localhost and 
two different ports, and then use a reverse proxy (like nginx) to multiplex 
connections and add HTTPS.

This way you can have one machine that responds to two distinct domains, each 
of which will point to one of your application.

… and if you use Caddy (https://caddyserver.com) instead of nginx you both get 
more Go code running and, more importantly, trivially easy Let’s Encrypt 
certificates.

//jb

-- 
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] Why so many opt-out changes to test runs in 1.10?

[Ondrej Fabry]

I must agree that Russ made some really valid points. I would like to see some 
concrete examples that contradict his reasoning.

-- 
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] Combine low traffic website

[Gianguido Sorà]

You could run the two programs on the same vps by binding them to localhost
and two different ports, and then use a reverse proxy (like nginx) to
multiplex connections and add HTTPS.

This way you can have one machine that responds to two distinct domains,
each of which will point to one of your application.

(I've sent this email before, but did not target the mailing list too.
Sorry about that.)


Il 08 dic 2017 20:52, "Andrew"  ha scritto:

I have two low traffic website with different domain names(Golang web app).
They are using https protocol(get certificate from let's encrypt)

I want to run them in one VPS to save money. How can I run these two web
apps in a single VPS?

Thanks.
Andrew

-- 
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] Combine low traffic website

[Andrew]

I have two low traffic website with different domain names(Golang web app). 
They are using https protocol(get certificate from let's encrypt)

I want to run them in one VPS to save money. How can I run these two web 
apps in a single VPS?

Thanks.
Andrew

-- 
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: Why so many opt-out changes to test runs in 1.10?

[Jakob Borg]

On 8 Dec 2017, at 20:07, krun...@compliahealth.com wrote:
> 
> I also agree with this.  While the feature is great I would expect base 
> functionality changes to be opt-in.

Go 1.10 in its entirety is opt-in. There’s plenty of time and opportunity to 
update build systems and processes before this is forced on anyone. Lets give 
it a chance, test, and help weed out any obvious issues before the release.

//jb

-- 
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: Why so many opt-out changes to test runs in 1.10?

[krunzer]

I also agree with this.  While the feature is great I would expect base 
functionality changes to be opt-in.

On Friday, December 8, 2017 at 9:28:47 AM UTC-8, Aaron Lefkowitz wrote:
>
> There's two features that are in Go 1.10 that are opt-out new defaults. I 
> sincerely apologize for not being active enough to spot them before now.
>
> > The go test command now caches test results: if the test executable and 
> command line match a previous run and the files and environment variables 
> consulted by that run have not changed either, go test will print the 
> previous test output, replacing the elapsed time with the string 
> “(cached).” Test caching applies only to successful test results; only to 
> go test commands with an explicit list of packages; and only to command 
> lines using a subset of the -cpu, -list, -parallel, -run, -short, and -v test 
> flags. The idiomatic way to bypass test caching is to use -count=1.
>
> There was some discussion on the Github issue that performance is the key 
> concern (as it usually is when caching comes into play): 
> https://github.com/golang/go/issues/11193
> However on a follow-up discussion it appears that it's actually fairly 
> impossible to be able to nail down the dependencies properly: 
> https://github.com/golang/go/issues/22593
> So the question would be why is this being introduced as an opt-out 
> feature, where it will cause many problems until people realize that their 
> test runs are being cached and disable it, which will lead to a "remember 
> to turn this off, it causes problems" feature, which would mean the default 
> is wrong. Why not do the easy fix here? There are people with problems in 
> this area because their tests don't need to be re-run and it costs them 
> significant amounts of time, why can't this simply be a -cache flag, not 
> only is this much more intuitive than -count=1 to disable caching in 
> general, but it preserves the behavior that: In most circumstances you will 
> probably just want your tests to run, even if they were successful the last 
> time, because something has changed; env, testdata, databases, external 
> golden files, etc. Or maybe you are trying to debug a flaky test (up-enter 
> enough times to get the intermittent error back now requires a -count=1).
>
> Let me be clear: This feature is amazing, and I want it. But I do think 
> the default is wrong.
>
> > The go test command now automatically runs go vet on the package being 
> tested, to identify significant problems before running the test. Any such 
> problems are treated like build errors and prevent execution of the test. 
> Only a high-confidence subset of the available go vet checks are enabled 
> for this automatic check. To disable the running of go vet, use go test 
> -vet=off.
>
> This is another opt-out change, why shouldn't it be an opt-in change? 
> Tools can easily be built around this to ensure that when a particular 
> project runs its tests it runs go vet first, this is trivial. You could 
> argue that the way this was implemented (being close to the toolchain) 
> makes it favorable to that solution because it's being run when there's 
> cycles to spare (during link) and therefore the performance impact should 
> be negligible. But then why just go vet? Why a subset of its checks? Why 
> not golint? If it's going to prevent me from running my tests and I have to 
> disable it in order to run these tests (despite being a valid Go program), 
> why are they not compiler errors?
>
> In this particular issue I think it's more about surprising behavior than 
> good defaults. It's surprising to me that go vet would prevent me from 
> running a test. If I don't run it now, and so it doesn't prevent me from 
> running tests, why should it in the future? It's surprising to me that 
> effectively a "linting tool" is being run automatically when I run tests. 
> It's surprising that when I compile a binary these same tests are not being 
> run, and do not prevent me from compiling the binary, but specifically 
> running tests, why is this? It's surprising to me that if I already run the 
> go vet check before tests in my project, I'm actually running it twice now 
> (in all projects that were savvy enough to already be doing this). It's 
> also surprising that it's been implemented at such a low level (directly 
> in the toolchain) when it's effectively just calling two commands in 
> succession.
>
> Is there some strong reason to have it in the toolchain which I'm not 
> seeing?
> Is there a good reason why it's on by default?
> Maybe the correct answer is to have go test -vet=on, where off is the 
> default?
>
> Just hoping to generate some discussion on the inclusion of these as 
> defaults. I think they're fine features, but they're certainly
> not for everyone, and I'm worried that the defaults might actually be much 
> more harmful than good (more in the test cache sense than in the vet sense).
>
> Aaron
>

-- 
You received this message 

[go-nuts] Re: [urgent] need aguments to justify use of Go for a scientific application

[as]

You are responsible for all problems related to the project after proposing 
a language. Caveat emptor.

- Go has a backwards compatibility promise. Go didn't change it's APIs and 
syntax after releasing a 1.0 version of the software.
- Go has formatting standards and a powerful standard library
- Go has code refactoring tools
- Go is a new language with decades of architectural and engineering work
- Authors worke(d) Bell Labs and Google, considered subject matter experts 
in their field
- Go is simple, which is integral to large projects and their 
maintainability
- Go is not a language associated with academia (it's more practical and 
less theoretical)
- There is a chance you will be paying someone to rewrite or port the 
Python version into a Go version later* 

*I speak from experience as someone who does this for C#, Python, C++ --> 
Go. Your mileage will vary on the veracity of this statement because this 
observation is anecdotal and not statistical.




On Wednesday, December 6, 2017 at 1:56:01 AM UTC-8, Christophe Meessen 
wrote:
>
> Hello, 
>
> I'm a computer scientist in charge of developing an image processing 
> pipeline for telescope images. 
> It will also have a web server and DB connection.
>
> The project is going through reviews by external experts, and the problem 
> I'm facing is that my proposal to use Go is about to be rejected. 
>
> The main opposing arguments are 
> - everybody uses python in astrophysics
> - it is very easy to find someone who knows python
> - risk that I, sole Go programmer, might become unavailable
>
> I would have the same arguments if I was project leader and unfamiliar 
> with Go. 
>
> The counter arguments I found so far are that
> - Go is simpler and safer than Python
> - I learned Go in a week-end
>
> The problem is that they don't convince people who don't know Go, are not 
> experienced software developers, and don't want to do the due diligence. 
> It's the usual inertia to change.  
>
> What other arguments could I use ?
>
> Do you know other significant scientific experiments that have adopted Go 
> ? 
>
>
>
> I have found this github project. 
> https://github.com/indigo-astronomy/indigo
> INDI is a well known Python Observatory Control System. 
> INDIGO is its translation into Go. 
>
> I have also found SciPipe https://github.com/scipipe.
> It is a Go pipeline framework used in scientific applications. 
>
>
>

-- 
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] Why so many opt-out changes to test runs in 1.10?

[Russ Cox]

First, a general point.

We care very much about getting the default experience right for Go users.
These features are opt-in because we believe in both cases that "on" is the
right default, that developers will be more productive with these on by
default than having to know to opt in.

- You should also not have to ask for "go test" to point out certainly
erroneous code instead of forcing you to find that code by debugging a test
failure.

- You should not have to ask for "go test ./...; modify a few source files;
go test ./..." to do the right thing and only rerun the test binaries
affected by your changes.

A new Go programmer who doesn't know these features exist should get the
benefit of these from day 1, without having to learn to set extra
configuration (which doesn't actually exist) or type extra arguments on
every go test command. Of course, turning them on by default means they
have to be right, and we're very sensitive to that. If you find concrete
examples where automatic vet or automatic test caching is causing you pain,
please file issues so that we can look to see if the defaults need further
adjustment. But please give them a chance first, actually try them, and
then report concrete problems, not hypotheticals based on simply reading
the release notes.

Now a few specifics.

For test caching:

> Or maybe you are trying to debug a flaky test (up-enter enough times to
get the intermittent error back now requires a -count=1).

Two things about this. First, you only have to type -count=1 once, since
the next up-enter will get it. But second, you may not have to type it all.
If the command you are running is "go test", with an implicit "test the
current directory", then there is no caching. See the description of "local
directory mode" in http://beta.golang.org/cmd/go/#hdr-Test_packages.

For vet during test:

> why just go vet?

Because vet is about correctness, and so is testing. If you are running "go
test", you are in effect saying "check for bugs in this package". If those
bugs can be reported directly - this line has this specific problem -
instead of indirectly as test failures, that seems like a win.

> Why a subset of its checks?

Because vet has historically been opt-in, not all of the checks are
appropriate to make opt-out. In particular, we won't enable a check during
'go test' unless it is accurate essentially 100% of the time, and if that
"essentially 100%" is not exactly 100%, there has to be a very clear
workaround. The idea is that vet sits quietly and you don't know it's
running until it speaks up with something important, something you actually
are happy to find out about and fix without debugging a test. If we are
falling short of that with a specific check, please file an issue with
concrete details.

> Why not golint?

Because golint is not about correctness. Golint is mostly about what your
code *looks* like, not what it means. The things it points out aren't
nearly important enough to block running a test.

> why are they not compiler errors?

There's a balance to strike here, again to make sure that opt-out is
reasonable. The code is valid Go code, as you say, so it probably should
continue to compile, especially if it's just someone else's dependency.
Maybe that code path never runs in the program being compiled. On the other
hand, when you are running "go test" of a specific package, you're asking
"check for bugs in this package", so that seems like exactly the right time
to subject that package's code (and only that package) to additional
correctness checks and report any problems.

Once again, please give these a chance, try them, and report problems on
the issue tracker, with concrete details. That's how we'll make sure these
are ready to be on by default.

Thanks for your help testing Go 1.10.

Best,
Russ

-- 
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: Why so many opt-out changes to test runs in 1.10?

[Robert Carlsen]

I also agree that the test caching should be opt-in.

On Friday, December 8, 2017 at 10:28:47 AM UTC-7, Aaron Lefkowitz wrote:
>
> There's two features that are in Go 1.10 that are opt-out new defaults. I 
> sincerely apologize for not being active enough to spot them before now.
>
> > The go test command now caches test results: if the test executable and 
> command line match a previous run and the files and environment variables 
> consulted by that run have not changed either, go test will print the 
> previous test output, replacing the elapsed time with the string 
> “(cached).” Test caching applies only to successful test results; only to 
> go test commands with an explicit list of packages; and only to command 
> lines using a subset of the -cpu, -list, -parallel, -run, -short, and -v test 
> flags. The idiomatic way to bypass test caching is to use -count=1.
>
> There was some discussion on the Github issue that performance is the key 
> concern (as it usually is when caching comes into play): 
> https://github.com/golang/go/issues/11193
> However on a follow-up discussion it appears that it's actually fairly 
> impossible to be able to nail down the dependencies properly: 
> https://github.com/golang/go/issues/22593
> So the question would be why is this being introduced as an opt-out 
> feature, where it will cause many problems until people realize that their 
> test runs are being cached and disable it, which will lead to a "remember 
> to turn this off, it causes problems" feature, which would mean the default 
> is wrong. Why not do the easy fix here? There are people with problems in 
> this area because their tests don't need to be re-run and it costs them 
> significant amounts of time, why can't this simply be a -cache flag, not 
> only is this much more intuitive than -count=1 to disable caching in 
> general, but it preserves the behavior that: In most circumstances you will 
> probably just want your tests to run, even if they were successful the last 
> time, because something has changed; env, testdata, databases, external 
> golden files, etc. Or maybe you are trying to debug a flaky test (up-enter 
> enough times to get the intermittent error back now requires a -count=1).
>
> Let me be clear: This feature is amazing, and I want it. But I do think 
> the default is wrong.
>
> > The go test command now automatically runs go vet on the package being 
> tested, to identify significant problems before running the test. Any such 
> problems are treated like build errors and prevent execution of the test. 
> Only a high-confidence subset of the available go vet checks are enabled 
> for this automatic check. To disable the running of go vet, use go test 
> -vet=off.
>
> This is another opt-out change, why shouldn't it be an opt-in change? 
> Tools can easily be built around this to ensure that when a particular 
> project runs its tests it runs go vet first, this is trivial. You could 
> argue that the way this was implemented (being close to the toolchain) 
> makes it favorable to that solution because it's being run when there's 
> cycles to spare (during link) and therefore the performance impact should 
> be negligible. But then why just go vet? Why a subset of its checks? Why 
> not golint? If it's going to prevent me from running my tests and I have to 
> disable it in order to run these tests (despite being a valid Go program), 
> why are they not compiler errors?
>
> In this particular issue I think it's more about surprising behavior than 
> good defaults. It's surprising to me that go vet would prevent me from 
> running a test. If I don't run it now, and so it doesn't prevent me from 
> running tests, why should it in the future? It's surprising to me that 
> effectively a "linting tool" is being run automatically when I run tests. 
> It's surprising that when I compile a binary these same tests are not being 
> run, and do not prevent me from compiling the binary, but specifically 
> running tests, why is this? It's surprising to me that if I already run the 
> go vet check before tests in my project, I'm actually running it twice now 
> (in all projects that were savvy enough to already be doing this). It's 
> also surprising that it's been implemented at such a low level (directly 
> in the toolchain) when it's effectively just calling two commands in 
> succession.
>
> Is there some strong reason to have it in the toolchain which I'm not 
> seeing?
> Is there a good reason why it's on by default?
> Maybe the correct answer is to have go test -vet=on, where off is the 
> default?
>
> Just hoping to generate some discussion on the inclusion of these as 
> defaults. I think they're fine features, but they're certainly
> not for everyone, and I'm worried that the defaults might actually be much 
> more harmful than good (more in the test cache sense than in the vet sense).
>
> Aaron
>

-- 
You received this message because you are subscribed to the Google Groups 

[go-nuts] Re: Why so many opt-out changes to test runs in 1.10?

[Markus Zimmermann]

I fully agree with Aaron. Both are fine additions but they should be opt-in 
instead of opt-out. "We" (and myself) have Vet in the linting stage of all 
of our projects. We do not want to run a static analysis in the test stage. 
Also, until the dependency issue is fixed for all possible scenarios I do 
not see this enabled either. Wasting CPU time is OK-ish, but wasting 
developer time for hunting down caching-problems is definitely not good.

On Friday, December 8, 2017 at 6:28:47 PM UTC+1, Aaron Lefkowitz wrote:
>
> There's two features that are in Go 1.10 that are opt-out new defaults. I 
> sincerely apologize for not being active enough to spot them before now.
>
> > The go test command now caches test results: if the test executable and 
> command line match a previous run and the files and environment variables 
> consulted by that run have not changed either, go test will print the 
> previous test output, replacing the elapsed time with the string 
> “(cached).” Test caching applies only to successful test results; only to 
> go test commands with an explicit list of packages; and only to command 
> lines using a subset of the -cpu, -list, -parallel, -run, -short, and -v test 
> flags. The idiomatic way to bypass test caching is to use -count=1.
>
> There was some discussion on the Github issue that performance is the key 
> concern (as it usually is when caching comes into play): 
> https://github.com/golang/go/issues/11193
> However on a follow-up discussion it appears that it's actually fairly 
> impossible to be able to nail down the dependencies properly: 
> https://github.com/golang/go/issues/22593
> So the question would be why is this being introduced as an opt-out 
> feature, where it will cause many problems until people realize that their 
> test runs are being cached and disable it, which will lead to a "remember 
> to turn this off, it causes problems" feature, which would mean the default 
> is wrong. Why not do the easy fix here? There are people with problems in 
> this area because their tests don't need to be re-run and it costs them 
> significant amounts of time, why can't this simply be a -cache flag, not 
> only is this much more intuitive than -count=1 to disable caching in 
> general, but it preserves the behavior that: In most circumstances you will 
> probably just want your tests to run, even if they were successful the last 
> time, because something has changed; env, testdata, databases, external 
> golden files, etc. Or maybe you are trying to debug a flaky test (up-enter 
> enough times to get the intermittent error back now requires a -count=1).
>
> Let me be clear: This feature is amazing, and I want it. But I do think 
> the default is wrong.
>
> > The go test command now automatically runs go vet on the package being 
> tested, to identify significant problems before running the test. Any such 
> problems are treated like build errors and prevent execution of the test. 
> Only a high-confidence subset of the available go vet checks are enabled 
> for this automatic check. To disable the running of go vet, use go test 
> -vet=off.
>
> This is another opt-out change, why shouldn't it be an opt-in change? 
> Tools can easily be built around this to ensure that when a particular 
> project runs its tests it runs go vet first, this is trivial. You could 
> argue that the way this was implemented (being close to the toolchain) 
> makes it favorable to that solution because it's being run when there's 
> cycles to spare (during link) and therefore the performance impact should 
> be negligible. But then why just go vet? Why a subset of its checks? Why 
> not golint? If it's going to prevent me from running my tests and I have to 
> disable it in order to run these tests (despite being a valid Go program), 
> why are they not compiler errors?
>
> In this particular issue I think it's more about surprising behavior than 
> good defaults. It's surprising to me that go vet would prevent me from 
> running a test. If I don't run it now, and so it doesn't prevent me from 
> running tests, why should it in the future? It's surprising to me that 
> effectively a "linting tool" is being run automatically when I run tests. 
> It's surprising that when I compile a binary these same tests are not being 
> run, and do not prevent me from compiling the binary, but specifically 
> running tests, why is this? It's surprising to me that if I already run the 
> go vet check before tests in my project, I'm actually running it twice now 
> (in all projects that were savvy enough to already be doing this). It's 
> also surprising that it's been implemented at such a low level (directly 
> in the toolchain) when it's effectively just calling two commands in 
> succession.
>
> Is there some strong reason to have it in the toolchain which I'm not 
> seeing?
> Is there a good reason why it's on by default?
> Maybe the correct answer is to have go test -vet=on, where off is the 
> default?
>
> 

Re: [go-nuts] Is this legit in cgo -- passing []*C.SQL_ERROR_TYPE to C

[Ian Lance Taylor]

On Fri, Dec 8, 2017 at 9:24 AM,   wrote:
>
> I am able to pass a []*C.SQL_ERROR_TYPE to C, allocate memory for
> SQL_ERROR_TYPE on the "C" side, populate the structure and access it on the
> Go side.  It works.  I tested Mac (High Sierra) and Linux 7, 64 bit.  Is
> this legitimate?  Or is it just happenstance that it is working?

I don't see any problem with this.

Presumably you'll want to have some way to free the C memory
later--the Go garbage collector won't do it for you.

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: Calculation of the combinations between an unlimited number of slices

[howardcshaw]

When you use append, two different things can happen:

1. There is enough capacity in the original slice to which you are 
appending to add the additional values. You get a slice that points to the 
same backing memory.
2. There is not enough capacity in the original slice to which you are 
appending. You get a slice that points to a newly allocated chunk of 
backing memory.

This blog talks specifically about append: https://blog.golang.org/slices

Now, looking at your code:

  
c1 := append(c, s)
temp = append(temp, c1)
fmt.Println(i,j,k, "- temp =", temp, " c=", c)

The key thing to see here, is that s is going to be added to c, and *c* is 
going to end up in c1, IF there is enough room for s in c. So, sometimes c1 
is pointing to the same bit of memory as c, sometimes a different bit.

I think, rather than making a copy of the temp variable c1, you should be 
doing the same thing at the step where you create c1.

In other words, something like
c1 := append([]int{}, c..., s)

-- 
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 1.10 Beta 1 is released

[Nate Finch]

"ResolveReference  now 
preseves"

*preserves

-- 
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] Why so many opt-out changes to test runs in 1.10?

[bits128]

There's two features that are in Go 1.10 that are opt-out new defaults. I 
sincerely apologize for not being active enough to spot them before now.

> The go test command now caches test results: if the test executable and 
command line match a previous run and the files and environment variables 
consulted by that run have not changed either, go test will print the 
previous test output, replacing the elapsed time with the string 
“(cached).” Test caching applies only to successful test results; only to go
 test commands with an explicit list of packages; and only to command lines 
using a subset of the -cpu, -list, -parallel, -run, -short, and -v test 
flags. The idiomatic way to bypass test caching is to use -count=1.

There was some discussion on the Github issue that performance is the key 
concern (as it usually is when caching comes into 
play): https://github.com/golang/go/issues/11193
However on a follow-up discussion it appears that it's actually fairly 
impossible to be able to nail down the dependencies 
properly: https://github.com/golang/go/issues/22593
So the question would be why is this being introduced as an opt-out 
feature, where it will cause many problems until people realize that their 
test runs are being cached and disable it, which will lead to a "remember 
to turn this off, it causes problems" feature, which would mean the default 
is wrong. Why not do the easy fix here? There are people with problems in 
this area because their tests don't need to be re-run and it costs them 
significant amounts of time, why can't this simply be a -cache flag, not 
only is this much more intuitive than -count=1 to disable caching in 
general, but it preserves the behavior that: In most circumstances you will 
probably just want your tests to run, even if they were successful the last 
time, because something has changed; env, testdata, databases, external 
golden files, etc. Or maybe you are trying to debug a flaky test (up-enter 
enough times to get the intermittent error back now requires a -count=1).

Let me be clear: This feature is amazing, and I want it. But I do think the 
default is wrong.

> The go test command now automatically runs go vet on the package being 
tested, to identify significant problems before running the test. Any such 
problems are treated like build errors and prevent execution of the test. 
Only a high-confidence subset of the available go vet checks are enabled 
for this automatic check. To disable the running of go vet, use go test 
-vet=off.

This is another opt-out change, why shouldn't it be an opt-in change? Tools 
can easily be built around this to ensure that when a particular project 
runs its tests it runs go vet first, this is trivial. You could argue that 
the way this was implemented (being close to the toolchain) makes it 
favorable to that solution because it's being run when there's cycles to 
spare (during link) and therefore the performance impact should be 
negligible. But then why just go vet? Why a subset of its checks? Why not 
golint? If it's going to prevent me from running my tests and I have to 
disable it in order to run these tests (despite being a valid Go program), 
why are they not compiler errors?

In this particular issue I think it's more about surprising behavior than 
good defaults. It's surprising to me that go vet would prevent me from 
running a test. If I don't run it now, and so it doesn't prevent me from 
running tests, why should it in the future? It's surprising to me that 
effectively a "linting tool" is being run automatically when I run tests. 
It's surprising that when I compile a binary these same tests are not being 
run, and do not prevent me from compiling the binary, but specifically 
running tests, why is this? It's surprising to me that if I already run the 
go vet check before tests in my project, I'm actually running it twice now 
(in all projects that were savvy enough to already be doing this). It's 
also surprising that it's been implemented at such a low level (directly in 
the toolchain) when it's effectively just calling two commands in 
succession.

Is there some strong reason to have it in the toolchain which I'm not 
seeing?
Is there a good reason why it's on by default?
Maybe the correct answer is to have go test -vet=on, where off is the 
default?

Just hoping to generate some discussion on the inclusion of these as 
defaults. I think they're fine features, but they're certainly
not for everyone, and I'm worried that the defaults might actually be much 
more harmful than good (more in the test cache sense than in the vet sense).

Aaron

-- 
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] Is this legit in cgo -- passing []*C.SQL_ERROR_TYPE to C

[asaaveri]

All:

I am able to pass a []*C.SQL_ERROR_TYPE to C, allocate memory for 
SQL_ERROR_TYPE on the "C" side, populate the structure and access it on the 
Go side.  It works.  I tested Mac (High Sierra) and Linux 7, 64 bit.  Is 
this legitimate?  Or is it just happenstance that it is working?

With regards,

package ttodbc

import "unsafe"
import "fmt"

/*
#include 
#include 
#include 

typedef struct sqlError {
  int recordNumber;
  char sqlState[32];
  int nativeError;
  char messageText[1024];
} SQL_ERROR_TYPE;

void *CSlice(void* slice) {
  int pos=0;
  SQL_ERROR_TYPE **tmp = (SQL_ERROR_TYPE **) slice;
  void *dummy;
  for (pos =0; pos < 16; pos++) {
printf("Populating %d\n", pos);
tmp[pos] = malloc(sizeof(SQL_ERROR_TYPE));
tmp[pos]->nativeError = pos+100;
tmp[pos]->recordNumber = pos;
strcpy(tmp[pos]->sqlState, "S1000");
  }
  dummy = malloc(sizeof(int) );
  return dummy;
}
*/
import "C"

func SliceToC() {
slice := make([]*C.SQL_ERROR_TYPE, 16)
ret := C.CSlice(unsafe.Pointer([0]))
fmt.Println("Ret %v", ret)
for i := 0; i < 16; i++ {
var tmp *C.SQL_ERROR_TYPE = slice[i]
fmt.Println("SQLState, native error: ", C.GoString([0]), 
uint(tmp.nativeError))
}
}

-- 
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: Newbie cgo question

[asaaveri]

Ian:

Thanks.

mp

On Thursday, December 7, 2017 at 9:47:28 AM UTC-7, M.P. Ardhanareeswaran 
wrote:
>
> All:
>
> I am working on a pilot go/cgo project for a database driver.  For one of 
> my C functions called by go, I chose a generic, unfortunate name 
> connect().  My program  kept dumping core on Linux.  I did some tracing and 
> found out that my function connect() was being called twice even though I 
> called it just once.  I renamed the function as myconnect() and the problem 
> went away.  Here is an nm output after the fact:
>
> 0277 T _cgo_c208fc38ae96_Cfunc_myconnect
> 0634 T myconnect
>
> Is this expected?  Is there a general pattern to protect against this?
>
> With regards,
>

-- 
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 1.10 Beta 1 is released

[Tamás Gulácsi]

2017. december 8., péntek 12:51:07 UTC+1 időpontban Gabriel Aszalos a 
következőt írta:
>
> > The grammar for method expressions has been updated to relax the syntax 
> to allow any type expression as a receiver; this matches what the compilers 
> were already implementing. For example, struct{io.Reader}.Read is a valid, 
> if unusual, method expression that the compilers already accepted and is 
> now permitted by the language grammar.
>
> I am quite curious - what was the reasoning behind this change? Is there a 
> thread or an issue anywhere that provides more context? Would love to 
> understand the use cases for this and the problem being solved. 
>

Using struct {
  io.Reader
  io.Closer
}{r, ioutil.NopCloser(nil)}

as an io.ReadCloser where it is required.

-- 
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 1.10 Beta 1 is released

[Ian Lance Taylor]

On Fri, Dec 8, 2017 at 3:51 AM, Gabriel Aszalos
 wrote:
>> The grammar for method expressions has been updated to relax the syntax to 
>> allow any type expression as a receiver; this matches what the compilers 
>> were already implementing. For example, struct{io.Reader}.Read is a valid, 
>> if unusual, method expression that the compilers already accepted and is now 
>> permitted by the language grammar.
>
> I am quite curious - what was the reasoning behind this change? Is there a 
> thread or an issue anywhere that provides more context? Would love to 
> understand the use cases for this and the problem being solved.

https://golang.org/issue/9060.

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] GoLang dependency -> dep installation Issue , Burrow golang tool issues

[Arun Singh]

Folks, 

I am new to Golang, I am installing Burrow 
 tool to fix and monitor the kafka 
consumer lag checking. Earlier this burrow was having "gpm" as package 
managment tool, Now some changes have been there in recent github repo 
update of this Burrow, In terms of getting started with golang setup, build 
and install Burrow, I am getting stuck in second process of prerquisite 
step, Let me know how to resolve this.

Prerequisites

Burrow is written in Go, so before you get started, you should install and 
set up Go.

If you have not yet installed the Go Dependency Management Tool 
, please go over there and follow their 
short installation instructions. dep is used to automatically pull in the 
dependencies for Burrow so you don't have to chase them all down.
--->> I am getting stuck here, Not able to install it on ubuntu, 
Kindly suggest how to overcome this. / Earlier I was able to install godep 
,gpm and make this repo work but not now when this "dep" update have been 
pushed to burrow github repo.


 # Build and Install

$ go get github.com/linkedin/Burrow# I have done this 
$ cd $GOPATH/src/github.com/linkedin/Burrow
$ dep ensure # since this is not installed, hence, not able to fix this.
$ go install

*Go env Information and Version.*


:~$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mpuser/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build014902965=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
mpuser@arbok:~$ go version
go version go1.9.2 linux/amd64

Kernel & OS information: Linux arbok 4.4.0-92-generic #115~14.04.1-Ubuntu SMP  
x86_64 x86_64 x86_64 GNU/Linux


I look forward to golang community suggestions.

~
Regards
Arun

-- 
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 1.10 Beta 1 is released

[Gabriel Aszalos]

> The grammar for method expressions has been updated to relax the syntax to 
> allow any type expression as a receiver; this matches what the compilers were 
> already implementing. For example, struct{io.Reader}.Read is a valid, if 
> unusual, method expression that the compilers already accepted and is now 
> permitted by the language grammar.

I am quite curious - what was the reasoning behind this change? Is there a 
thread or an issue anywhere that provides more context? Would love to 
understand the use cases for this and the problem being solved. 

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