[go-nuts] Lazy Bash redirection

[juicemia]

Hi everybody.

I don't know if this question has been asked before, partially because I 
don't really even know what to call what I'm trying to do.

The best I can come up with is that I'm trying to do lazy redirection in 
bash but I'm having some trouble.

A concrete example should help explain:

I have a Go program. Part of this program's execution is to open up Vim for 
some editing. The user can then save and close, and the program will 
continue working using the user's input into Vim.

That works well. However, it breaks down when I do something like the 
following:

program | grep 'foo'

When I do this, Vim complains about stdout not being a terminal. I realize 
this is because the pipe redirects the stdout of program to the stdin of 
grep _before_ the execution of program, not after.

Is there any way I can get the redirection to happen _after_ program has 
executed?

-- 
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: can't open file if its name was read from stdin

[Uli Kunitz]

Good, that you found the problem yourself. I wasn't aware that you were on 
Windows were newlines are represented by CRLF ("\r\n"). TrimSpace would 
deal with that as well.

-- 
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] Should we stop using a global logger?

[Ian Ross]

I have fiound when you start tracing (e.g jaeger by Uber), you start 
logging properly and realise it should only used when something needs to be 
done by an admin.

On Friday, August 25, 2017 at 12:00:38 PM UTC+1, Peter Mogensen wrote:
>
>
>
> On 2017-08-25 12:53, Henrik Johansson wrote: 
> > Yes it works ok we have done it as well but a common interface wouldbe 
> > convenient. Especially when opentracing whose Go libs seems to take off 
> > nicely with afaik a common interface. Logging seems even simpler. 
> > 
> > I have started to use Zap pervasively and its typed API is very neat. 
>
> I did a survey involving basically every logger library I could find 
> some time ago and ended up concluding that non of them had an easy way 
> to do logging to systemd in the form "message" on stdout/stderr. 
> (where X is the syslog level). 
> So we ended up doing our own logging library. I don't think Zap was 
> around at the time. 
>
> Yeah... I know... The log15 author has a point. But I find the result 
> pretty useful. 
>
> /Peter 
>

-- 
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 1.9: New Helper() method in testing package does not work with testing.TB interface

[Caleb Spare]

That's not a mistake. It's still a bug! Just doesn't seem like a very
severe one. I filed https://github.com/golang/go/issues/21631.

On Fri, Aug 25, 2017 at 3:08 PM, lukas.malkmus via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'm sorry, I think I made a huge mistake. The malicious output only occurs
> when running go test with the -race flag.
>
> Am Freitag, 25. August 2017 22:35:21 UTC+2 schrieb
> lukas@googlemail.com:
>
>> I'm using helper functions in my test, for example this one:
>>
>> // assert fails the test if the condition is false.
>> func assert(tb testing.TB, condition bool, msg string, v ...interface{})
>> {
>>  if !condition {
>>  _, file, line, _ := runtime.Caller(1)
>>  fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
>> filepath.Base(file), line}, v...)...)
>>  tb.FailNow()
>>  }
>> }
>>
>> I hoped that I could improve these helpers with the new (*B).Helper() and
>> (*T).Helper() methods:
>>
>> // assert fails the test if the condition is false.
>> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
>> tb.Helper()
>> if !condition {
>> tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
>> }
>> }
>>
>> I expected Go to print the file and line number of the failing test,
>> followed by a red message. Instead, the file and line number is of form "
>> :1:"
>>
>> It works if I replace tb testing.TB with t testing.T. Is there a reason
>> the new Helper() method is part of the TB interface but not working as
>> expected? Or could it be a bug?
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 1.9 failing with excelize (simple case works under 1.8.3)

[G Shields]

Under 1.8.3 the program run:
package main

import (
"fmt"
"os"
"strconv"

"github.com/Luxurioust/excelize"
)

func checkErr(err error) {
if err != nil {
fmt.Println(err)
os.Exit(1)
}

}
func main() {

xlsx, err := excelize.OpenFile("test.xlsx")
checkErr(err)
mysheet := xlsx.GetSheetName(1)
index := xlsx.GetSheetIndex(mysheet)
rows := xlsx.GetRows("Sheet" + strconv.Itoa(index))
for _, row := range rows {
for _, colCell := range row {
fmt.Print(colCell, "\t")
}
fmt.Println()
}
}

With results of:
naAppleOrangePear
Small233
Normal524
Large678
Success: process exited with code 0.

Under 1.9 I get no data and no errors:
Success: process exited with code 0.

-- 
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.9: New Helper() method in testing package does not work with testing.TB interface

[lukas.malkmus via golang-nuts]

I'm sorry, I think I made a huge mistake. The malicious output only occurs 
when running go test with the -race flag.

Am Freitag, 25. August 2017 22:35:21 UTC+2 schrieb lukas@googlemail.com:
>
> I'm using helper functions in my test, for example this one:
>
> // assert fails the test if the condition is false.
> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
>  if !condition {
>  _, file, line, _ := runtime.Caller(1)
>  fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
> filepath.Base(file), line}, v...)...)
>  tb.FailNow()
>  }
> }
>
> I hoped that I could improve these helpers with the new (*B).Helper() and 
> (*T).Helper() methods:
>
> // assert fails the test if the condition is false.
> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
> tb.Helper()
> if !condition {
> tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
> }
> }
>
> I expected Go to print the file and line number of the failing test, 
> followed by a red message. Instead, the file and line number is of form "
> :1:"
>
> It works if I replace tb testing.TB with t testing.T. Is there a reason 
> the new Helper() method is part of the TB interface but not working as 
> expected? Or could it be a bug?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.9 is released

[ahhb1965]

Just wanted to thank everyone who made this 10th release possible ! Great 
work to common and my personal benefit ! Thank You !
Andreas 

On Friday, 25 August 2017 00:44:25 UTC+2, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
 

> 
>
> 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: can't open file if its name was read from stdin

[Geoff Fridd]

I found the solution myself - when read in from stdin, there are 2 extra 
characters - CR and LF.  I just cut the string 2 characters before the end, 
and it works!  Thanks to those for posting replies!

On Thursday, August 24, 2017 at 11:35:31 PM UTC-4, Geoff Fridd wrote:
>
> Does anyone know why Google Go program 1 works, below, and program 2 
> doesn't? The only difference - I read in the filename from the console in 
> the one that doesn't work but it is a literal in the one that works... I 
> tried typing in the full path for the file, and also "..sample.txt" instead 
> of "sample.txt", but they didn't solve it either.
> // program 1 - this works:
>
> package main import (
> "fmt"
> "os"
> "bufio" )
> 
> func main() { 
> filename := getFilename()
> fmt.Println("opening:",filename) 
> //  fmt.Println("opening:sample.txt") 
> _ , err := os.Open("sample.txt") 
> //   _ , err := os.Open(filename) 
> if err != nil { 
> panic(err) 
> } 
> } 
>
> func getFilename()  string {
> reader := bufio.NewReader(os.Stdin)
> fmt.Print("Enter file name: ")// type in anything, this file 
> name not used
> filename, _ := reader.ReadString('\n')
> return filename
> }
>
>
> // program 2 - this doesn't work, gives error shown below:
>
> package main
> import (
> "fmt"
> "os"
> "bufio"
> )
> 
> func main() 
> filename := getFilename()
> fmt.Println("opening:",filename)
> // fmt.Println("opening: sample.txt")
> // _ , err := os.Open("sample.txt")
> _ , err := os.Open(filename)
> if err != nil {
> panic(err)
> }
> }
>
> func getFilename()  string {
> reader := bufio.NewReader(os.Stdin)
> fmt.Print("Enter file name: ")// type in "sample.txt" (without 
> the quotes)
> filename, _ := reader.ReadString('\n')
> return filename
> }
>
> Error message, panic invoked - 
> : The filename, directory name, or volume label syntax is incorrect.
>
> goroutine 1 [running]:
> main.main()
> C:/installed programs/go/src/testopen2.go:16 +0x158
> exit status 2
>
>

-- 
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 1.9: New Helper() method in testing package does not work with testing.TB interface

[Caleb Spare]

Yeah, sorry, I misread the report.

I can't reproduce the issue. Can you give a complete runnable example.

On Fri, Aug 25, 2017 at 1:46 PM, lukas.malkmus via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> It is part of the interface...
>
>
> Am Freitag, 25. August 2017 22:35:21 UTC+2 schrieb
> lukas@googlemail.com:
>>
>> I'm using helper functions in my test, for example this one:
>>
>> // assert fails the test if the condition is false.
>> func assert(tb testing.TB, condition bool, msg string, v ...interface{})
>> {
>>  if !condition {
>>  _, file, line, _ := runtime.Caller(1)
>>  fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
>> filepath.Base(file), line}, v...)...)
>>  tb.FailNow()
>>  }
>> }
>>
>> I hoped that I could improve these helpers with the new (*B).Helper() and
>> (*T).Helper() methods:
>>
>> // assert fails the test if the condition is false.
>> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
>> tb.Helper()
>> if !condition {
>> tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
>> }
>> }
>>
>> I expected Go to print the file and line number of the failing test,
>> followed by a red message. Instead, the file and line number is of form "
>> :1:"
>>
>> It works if I replace tb testing.TB with t testing.T. Is there a reason
>> the new Helper() method is part of the TB interface but not working as
>> expected? Or could it be a bug?
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.9: New Helper() method in testing package does not work with testing.TB interface

[lukas.malkmus via golang-nuts]

It is part of the interface...

Am Freitag, 25. August 2017 22:35:21 UTC+2 schrieb lukas@googlemail.com:
>
> I'm using helper functions in my test, for example this one:
>
> // assert fails the test if the condition is false.
> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
>  if !condition {
>  _, file, line, _ := runtime.Caller(1)
>  fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
> filepath.Base(file), line}, v...)...)
>  tb.FailNow()
>  }
> }
>
> I hoped that I could improve these helpers with the new (*B).Helper() and 
> (*T).Helper() methods:
>
> // assert fails the test if the condition is false.
> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
> tb.Helper()
> if !condition {
> tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
> }
> }
>
> I expected Go to print the file and line number of the failing test, 
> followed by a red message. Instead, the file and line number is of form "
> :1:"
>
> It works if I replace tb testing.TB with t testing.T. Is there a reason 
> the new Helper() method is part of the TB interface but not working as 
> expected? Or could it be a bug?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] go 1.9: New Helper() method in testing package does not work with testing.TB interface

[Caleb Spare]

I filed https://github.com/golang/go/issues/21627. Thanks for the heads up.

On Fri, Aug 25, 2017 at 1:39 PM, Caleb Spare  wrote:

> Oh, shoot. It should be part of the interface. That was part of the
> proposal:
>
> https://github.com/golang/proposal/blob/master/design/
> 4899-testing-helper.md
>
> but I forgot to add it.
>
> On Fri, Aug 25, 2017 at 1:16 PM, lukas.malkmus via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> I'm using helper functions in my test, for example this one:
>>
>> // assert fails the test if the condition is false.
>> func assert(tb testing.TB, condition bool, msg string, v ...interface{})
>> {
>>  if !condition {
>>  _, file, line, _ := runtime.Caller(1)
>>  fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
>> filepath.Base(file), line}, v...)...)
>>  tb.FailNow()
>>  }
>> }
>>
>> I hoped that I could improve these helpers with the new (*B).Helper() and
>> (*T).Helper() methods:
>>
>> // assert fails the test if the condition is false.
>> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
>> tb.Helper()
>> if !condition {
>> tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
>> }
>> }
>>
>> I expected Go to print the file and line number of the failing test,
>> followed by a red message. Instead, the file and line number is of form "
>> :1:"
>>
>> It works if I replace tb testing.TB with t testing.T. Is there a reason
>> the new Helper() method is part of the TB interface but not working as
>> expected? Or could it be a bug?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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.9: New Helper() method in testing package does not work with testing.TB interface

[Caleb Spare]

Oh, shoot. It should be part of the interface. That was part of the
proposal:

https://github.com/golang/proposal/blob/master/design/4899-testing-helper.md

but I forgot to add it.

On Fri, Aug 25, 2017 at 1:16 PM, lukas.malkmus via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> I'm using helper functions in my test, for example this one:
>
> // assert fails the test if the condition is false.
> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
>  if !condition {
>  _, file, line, _ := runtime.Caller(1)
>  fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
> filepath.Base(file), line}, v...)...)
>  tb.FailNow()
>  }
> }
>
> I hoped that I could improve these helpers with the new (*B).Helper() and
> (*T).Helper() methods:
>
> // assert fails the test if the condition is false.
> func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
> tb.Helper()
> if !condition {
> tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
> }
> }
>
> I expected Go to print the file and line number of the failing test,
> followed by a red message. Instead, the file and line number is of form "
> :1:"
>
> It works if I replace tb testing.TB with t testing.T. Is there a reason
> the new Helper() method is part of the TB interface but not working as
> expected? Or could it be a bug?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.9: New Helper() method in testing package does not work with testing.TB interface

[lukas.malkmus via golang-nuts]

I'm using helper functions in my test, for example this one:

// assert fails the test if the condition is false.
func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
 if !condition {
 _, file, line, _ := runtime.Caller(1)
 fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{
filepath.Base(file), line}, v...)...)
 tb.FailNow()
 }
}

I hoped that I could improve these helpers with the new (*B).Helper() and 
(*T).Helper() methods:

// assert fails the test if the condition is false.
func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
tb.Helper()
if !condition {
tb.Fatalf("\033[31m "+msg+"\033[39m\n\n", v...)
}
}

I expected Go to print the file and line number of the failing test, 
followed by a red message. Instead, the file and line number is of form "
:1:"

It works if I replace tb testing.TB with t testing.T. Is there a reason the 
new Helper() method is part of the TB interface but not working as 
expected? Or could it be a bug?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: OT: (NOOB) Settings GOROOT and GOPATH on Freebsd

[mrpa . android]

I found a solution that solved my problem, now using FreeBSD 11.1 x86_64

Nginx Reverse Proxy and Golang Setup on FreeBSD
Source: 
https://www.vultr.com/docs/nginx-reverse-proxy-and-golang-setup-on-freebsd

Requirements

Basic knowledge of UNIX.
FreeBSD x64 with Nginx installed.
Install Tools

You will need several programs that are not shipped with FreeBSD. Run the 
following command to install them:

pkg install nano wget git mercurial bzr
Download and Install Golang

Download golang by running the following set of commands:

cd /tmp
wget https://storage.googleapis.com/golang/go1.3.3.freebsd-amd64.tar.gz
tar -C /usr/local -xzf go1.3.3.freebsd-amd64.tar.gz
Setup Environment Variables

Create a variable called GOPATH (which will be the location for installed 
packages) and add it to your path:

mkdir ~/.gopkg
setenv GOPATH /root/.gopkg
set path = ($path /usr/local/go/bin /root/.gopkg/bin)
If you want to have the path set on boot, then run the following command to 
add it to your .cshrc:

echo "setenv GOPATH /root/.gopkg" >> ~/.cshrc
echo "set path = ($path /usr/local/go/bin /root/.gopkg/bin)" >> ~/.cshrc
Verify Installation

Run go in your terminal. If you are presented with a list of options, then 
the installation was successful. Run the following command to install a web 
framework called Martini:

go get github.com/go-martini/martini
If you don't see any errors, then you may proceed to the next step.

Setup Martini

Create a file called server.go and populate it with the following lines of 
code:

package main

import "github.com/go-martini/martini"

func main() {
  m := martini.Classic()
  m.Get("/", func() string {
return "Hello from Vultr VPS :)!"
  })
  m.Run()
}

When done, save and run go run server.go. Provided that you do not see any 
errors on your terminal, then you can proceed to the next step.

@firebitsbr


Em domingo, 22 de dezembro de 2013 03:00:02 UTC-2, Mauro Risonho de Paula 
Assumpção escreveu:
>
> I'm trying to use and compile programs made in golang on freebsd 9.2 and 
> 10.0 rc1, but I'm problems setting variables and GOROOT GOPATH environment.
>
> I'm trying to use command:
>
> export
> setenv
>
> But, unsuccessfully.
>
> Has anyone managed to solve this?
>
> @firebitsbr
>

-- 
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: [golang-dev] Go 1.9 is released

[Steven Hartland]

On 25/08/2017 17:39, Ian Lance Taylor wrote:

On Fri, Aug 25, 2017 at 1:53 AM, Steven Hartland  wrote:

One thing I've noticed, having read through the blog post and release notes,
is a mention of the issue with the netpoller is surprisingly absent.

This issue has bitten us quite a bit, only tracked it down this week, so
would have expected to see this one to mentioned given it can and does cause
TCP connections from the runtime to fail randomly; something worth adding?

In general we don't mention every bug fix in the release notes, and
this one is fairly uncommon, and I think mainly occurs when trying to
connect to a TCP port on which nothing is listening.  That said, if
you want to send in a patch for the release notes, that would be fine.
Thanks.

Ian
Thanks for the response Ian, if this was rare here I would agree, but 
prior to deploying a 1.9 build, we were experiencing this many times a 
day on a reconciliation daemon we have which talks to GCE API so we 
believe its more common than people may think.


My guess would be there aren't more reports because its hard to track 
and people just retry assuming its a network glitch.


I'll look to create a patch.

    Regards
    Steve

--
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] https://golang.org/pkg/builtin/#append

[Ian Lance Taylor]

On Fri, Aug 25, 2017 at 11:28 AM,   wrote:
> looks broken here
>
> __
>
> File builtin
>
> builtin
>
> /src/builtin/builtin.go:88:11: expected type, found '=' (and 1 more errors)

https://golang.org/issue/21601

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] Getting the current process signal disposition

[Ian Lance Taylor]

On Fri, Aug 25, 2017 at 11:09 AM, adam.azarchs via golang-nuts
 wrote:
> TL;DR it would be nice if there were a public API to find the current signal
> disposition of your process.  The runtime already stores that information in
> runtime.sigtable, but doesn't expose it.
>
> I ran into a gotcha with handling SIGHUP the other day.  I need to handle
> SIGHUP in order to shut down gracefully.  However, nohup works by setting
> the process's signal disposition to ignore SIGHUP, and adding a handler
> un-ignores the signal, meaning the process shuts down when it shouldn't.
> Figuring out whether it was ignored, however, proved unpleasantly difficult.
> I know this would be straightforward enough to solve with cgo, but that
> opens us up to deployment difficulties for customers with older libc.  It's
> a bit aggravating that the runtime already has the information I want but
> doesn't give me a way to see it.  For the moment I'm just making the syscall
> but this seems like information the os/signal package should expose, for
> people who for example want to know what signal.Reset is resetting things
> *to*.

This seems reasonable to me.  I've seen it as being desirable in other
contexts.  If you can think of a good API to add the os/signal
package, please open an issue at https://golang.org/issue with a
proposal.  You make an important point--we need to report not just the
os/signal dispositions, but the internal runtime dispositions.
Thanks.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: can't use text filename on open that was read from stdin

[mhhcbon]

someone did answer you in your earlier thread,

but here you go

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



On Friday, August 25, 2017 at 9:18:18 PM UTC+2, Geoff Fridd wrote:
>
> When I use a literal as the filename in an os.Open statement it works. 
> When I use a variable defined as text as the filename, it works. When I 
> read in the text filename from stdin, it doesn't work. Why is that? What do 
> I need to do to make it work? See attached text file.
>
>
>

-- 
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] Help! Same code, different results

[Tong Sun]

[resent to group, sorry Egon]

On Fri, Aug 25, 2017 at 3:04 PM, Egon  wrote:

> Try to find the first place where the processes diverge:
>
> 1. maybe find lists files in different order
>

Oh, YES! BINGO! THANKS A LOT.

find test/sim -type f* | sort* | ./fsimilar -i -d 12 -vv

gave me the correct output that i want.

Ah~, my algorithm is so fragile. :(


> 2. maybe something read input does things in different order
> 3. maybe some processing uses maps --> hence random order
> 4. etc...
>
> (of course run with -race, if you already haven't)
>
> On Friday, 25 August 2017 21:56:29 UTC+3, Tong Sun wrote:
>>
>>
>> Update,
>>
>>
>> On Fri, Aug 25, 2017 at 11:39 AM, Tong Sun  wrote:
>>
>>> Hi,
>>>
>>> I'm experiencing a *very very* strange problem now -- the same Go code
>>> is producing different results *for me*.
>>> I'm not kidding, I can't believe that myself, so I've spent *the past
>>> few days* going back and forth to verify everything.
>>> Now, after all these days, the only conclusion that I can make is,
>>> albeit how bazzard it is, same code, different results.
>>>
>>> Can someone verify for me what you get please?
>>>
>>> go get github.com/go-dedup/fsimilar
>>>
>>> then
>>>
>>> cd go-dedup/fsimilar
>>> go build
>>> find test/sim -type f | ./fsimilar -i -d 12 -vv
>>>
>>> and tell me what's the last output that you got please.
>>>
>>> The problem is that *two *of my machines produce:
>>>
>>> [fsimilar] ## Similar items
>>>  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU -
>>> 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU
>>> - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/
>>> Hash:6184610222622303958 Dist:0 SizeRef:1]]].
>>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>>> *test/sim/GNU - Python Standard Library (2001).rar*
>>>
>>> But another one, the *only one*, produce:
>>>
>>> [fsimilar] ## Similar items
>>>  map[Similars:[{(eBook) GNU - Python Standard Library 2001 .pdf 1
>>> test/sim/ 15408562819203262167 8 1} {GNU - 2001 - Python Standard Library
>>> .pdf 1 test/sim/ 6184610222622303958 0 1} {GNU - Python Standard Library
>>> (2001) .rar 1 test/sim/ 6184610222622303958 0 1} {Python Standard Library
>>> .zip 1 test/sim/ 6175699711939618002 11 1}]].
>>> *test/sim/(eBook) GNU - Python Standard Library 2001.pdf*
>>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>>> *test/sim/GNU - Python Standard Library (2001).rar*
>>> *test/sim/Python Standard Library.zip*
>>>
>>> which is what I actually want.
>>>
>>> The rest of the following output are exactly the same across all three
>>> machines:
>>>
>>> $ go version
>>> go version go1.8.1 linux/amd64
>>>
>>> $ lsb_release -a
>>> No LSB modules are available.
>>> Distributor ID: Ubuntu
>>> Description:Ubuntu 17.04
>>> Release:17.04
>>> Codename:   zesty
>>>
>>> $ git status
>>> On branch master
>>> Your branch is up-to-date with 'origin/master'.
>>> nothing to commit, working tree clean
>>>
>>>
>> - all the original source on three machines are pulled from the same
>> git, with same status.
>> - I copied the bad code into good machine, and compared the two folders,
>> and files are the same
>> - I ran the bad code in good machine, and the result is the bad code
>> works in the good machine.
>> - I copied the good code into bad machine, and the result is good code
>> doesn't work in bad machine any more.
>>
>> Adding *all these things* up *I'm sure the code are the same *-- the
>> only different is the machine/build environment.
>>
>> I installed from https://storage.googleapis.com/golang/go1.8.3.linux-
>> amd64.tar.gz to both machines. and Now both machines have go1.8.3:
>>
>> $ type go
>> go is hashed (/opt/bin/go)
>>
>> $ go version
>> go version go1.8.3 linux/amd64
>>
>>
>> And having updgraded `github.com/fatih/structs`
>>  on the good machine, the following is
>> no longer an issue any more.
>>
>> Oh, I do get one difference to illustrate how strange things are -- for
>>> the same code of:
>>>
>>> verbose(2, "## Similar items\n *%v*.", m)
>>>
>>> The working machine produces (last two line):
>>>
>>> [fsimilar] ## Similar items
>>>  map[Similars:*[{*Improve Soccer Shooting Technique .mp4 10043873 ./Try
>>> These Soccer Drills/ 1808297800170271 0 10043873} {Improve Soccer
>>> Shooting Technique .mp4 10043873 ./Top Soccer Training Videos/
>>> 1808297800170271 0 10043873}]].
>>> [fsimilar] ## Similar items
>>>  map[Similars:*[{*Soccer Drills For Youth .mp4 11650500 ./Youth Soccer
>>> Training Drills/ 18062776733066936110 0 11650500} {Soccer Drills For Youth
>>> .mp4 11650500 ./Top Soccer Training Videos/ 18062776733066936110 0
>>> 11650500}]].
>>>
>>>
>>> while the machine with incorrect result produces (last two line):
>>>
>>> [fsimilar] ## Similar items
>>>  map[Similars:[*map*[Ext:.mp4 Size:10043873 Dir:./Try These Soccer
>>> Drills/ Hash:1808297800170271 

[go-nuts] can't use text filename on open that was read from stdin

[Geoff Fridd]

When I use a literal as the filename in an os.Open statement it works. When 
I use a variable defined as text as the filename, it works. When I read in 
the text filename from stdin, it doesn't work. Why is that? What do I need 
to do to make it work? See attached text file.


-- 
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.
Does anyone know why program 1 works, below, and program 2 doesn't? \the only 
difference - I read in the filename from the console in the one that doesn't 
work
// program 1 - this works:
package main
import (
"fmt"
"os"
"bufio"
)
func main() {
filename := getFilename()
fmt.Println("opening:",filename)
//  fmt.Println("opening: sample.txt")
_ , err := os.Open("sample.txt")
//  _ , err := os.Open(filename)
if err != nil {
panic(err)
}
}
func getFilename()  string {
reader := bufio.NewReader(os.Stdin)
fmt.Print("Enter file name: ")
filename, _ := reader.ReadString('\n')  // filename not used
return filename
}

// program 2 - this doesn't work, gives error shown below:
package main
import (
"fmt"
"os"
"bufio"
)
func main() {
filename := getFilename()
fmt.Println("opening:",filename)
//  fmt.Println("opening: sample.txt")
//  _ , err := os.Open("sample.txt")
_ , err := os.Open(filename)
if err != nil {
panic(err)
}
}
func getFilename()  string {
reader := bufio.NewReader(os.Stdin)
fmt.Print("Enter file name: ")  // here enter "sample.txt" (without the 
quotes)
filename, _ := reader.ReadString('\n')  // filename read in is used
return filename
}
Error message, panic invoked - 
: The filename, directory name, or volume label syntax is incorrect.

goroutine 1 [running]:
main.main()
C:/installed programs/go/src/testopen2.go:16 +0x158
exit status 2

[go-nuts] Re: const vs global variables in go

[T L]

On Wednesday, August 23, 2017 at 8:49:39 AM UTC-4, Alkesh Ghorpade wrote:
>
> Hi All,
>
> I am new to Go and trying to figure out difference between const vs var 
> variables memory usage and initialization.
>
> I have following go code
> // way 1
> var a = []string{"abc", "def"}
>
> // way 2
> const (
>  a = "abc"
>  b = "def"
> )
>
> var a1 = []string{a, b}
>
> my variables a and a1 are defined in a file and not inside any function. 
> Is there any difference in both ways. When I call variable a in any 
> function does it creates a copy everytime it is called? Can you please tell 
> me what happens when a or a1 is called and how they are referenced in 
> memory when called.
>

a and a1 have no differences. For this specified example, defining the 
consts is a non-sense.
when a and a1 are used elsewhere, their direct parts will be copied but 
their underlying parts will not be copied.
copying their direct parts is very cheap operation.

http://www.tapirgames.com/blog/golang-underlying-values

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Help! Same code, different results

[Tong Sun]

Thanks a lot my friend.

That's something I'm afraid of.


On Fri, Aug 25, 2017 at 3:02 PM,  wrote:

> [mh-cbon@pc2 rendez-vous] $ cd ../../go-dedup/fsimilar/
> [mh-cbon@pc2 fsimilar] $ find test/sim -type f | ./fsimilar -i -d 12 -vv
> [fsimilar]  n='GNU - 2001 - Python Standard Library', e='.pdf', s='1', d=
> 'test/sim/'
> [fsimilar] +: Simhash of 55d4263ae1a6e6d6 added.
> [fsimilar]  n='(eBook) GNU - Python Standard Library 2001', e='.pdf', s=
> '1', d='test/sim/'
> [fsimilar] =: Simhash of d5d6363ef9e6e6d7 ignored for 55d4263ae1a6e6d6 (8
> ).
> [fsimilar]  n='GNU - Python Standard Library (2001)', e='.rar', s='1', d=
> 'test/sim/'
> [fsimilar] =: Simhash of 55d4263ae1a6e6d6 ignored for 55d4263ae1a6e6d6 (0
> ).
> [fsimilar]  n='Python Standard Library', e='.zip', s='1', d='test/sim/'
> [fsimilar] =: Simhash of 55b47e2af1a4a4d2 ignored for 55d4263ae1a6e6d6 (11
> ).
> [fsimilar]  n='Audio Book - The Grey Coloured Bunnie', e='.mp3', s='1', d=
> 'test/sim/'
> [fsimilar] +: Simhash of f8fde9fe7f7dbd5e added.
> [fsimilar]  n='PopupTest', e='.java', s='1', d='test/sim/'
> [fsimilar] +: Simhash of a0d9070f13c20979 added.
> [fsimilar]  n='LayoutTest', e='.java', s='1', d='test/sim/'
> [fsimilar] +: Simhash of 37299e9d4e277b87 added.
> [fsimilar]  n='ColoredGrayBunny', e='.ogg', s='1', d='test/sim/'
> [fsimilar] +: Simhash of 25eade3cd3db679c added.
> [fsimilar] ## Similar items
>  map[Similars:[map[Ext:.pdf Size:1 Dir:test/sim/ Hash:6184610222622303958
> Dist:0 SizeRef:1 Name:GNU - 2001 - Python Standard Library] map[Size:1 Dir
> :test/sim/ Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - Python
> Standard Library (2001) Ext:.rar]]].
> test/sim/GNU - 2001 - Python Standard Library.pdf
> test/sim/GNU - Python Standard Library (2001).rar
>
>
> [mh-cbon@pc2 fsimilar] $ go version
> go version go1.8 linux/amd64
> [mh-cbon@pc2 fsimilar] $ go env
> GOARCH="amd64"
> GOBIN="/home/mh-cbon/gow/bin"
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOOS="linux"
> GOPATH="/home/mh-cbon/gow"
> GORACE=""
> GOROOT="/home/mh-cbon/.gvm/gos/go1.8"
> GOTOOLDIR="/home/mh-cbon/.gvm/gos/go1.8/pkg/tool/linux_amd64"
> GCCGO="gccgo"
> CC="gcc"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0
> -fdebug-prefix-map=/tmp/go-build580933895=/tmp/go-build
> -gno-record-gcc-switches"
> CXX="g++"
> CGO_ENABLED="1"
> PKG_CONFIG="pkg-config"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> [mh-cbon@pc2 fsimilar] $ git log -n 1
> commit 10c9f3f50da4f00f7fd874c24aa7c7787dcf275e (HEAD -> master, origin/
> master, origin/HEAD)
> Author: Tong Sun 
> Date:   Thu Aug 24 00:36:37 2017 -0400
>
> - [+] add FileT.Similarity()
> [mh-cbon@pc2 fsimilar] $
>
> hth
>
>
> On Friday, August 25, 2017 at 8:56:29 PM UTC+2, Tong Sun wrote:
>>
>>
>> Update,
>>
>>
>> On Fri, Aug 25, 2017 at 11:39 AM, Tong Sun  wrote:
>>
>>> Hi,
>>>
>>> I'm experiencing a *very very* strange problem now -- the same Go code
>>> is producing different results *for me*.
>>> I'm not kidding, I can't believe that myself, so I've spent *the past
>>> few days* going back and forth to verify everything.
>>> Now, after all these days, the only conclusion that I can make is,
>>> albeit how bazzard it is, same code, different results.
>>>
>>> Can someone verify for me what you get please?
>>>
>>> go get github.com/go-dedup/fsimilar
>>>
>>> then
>>>
>>> cd go-dedup/fsimilar
>>> go build
>>> find test/sim -type f | ./fsimilar -i -d 12 -vv
>>>
>>> and tell me what's the last output that you got please.
>>>
>>> The problem is that *two *of my machines produce:
>>>
>>> [fsimilar] ## Similar items
>>>  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU -
>>> 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU
>>> - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/
>>> Hash:6184610222622303958 Dist:0 SizeRef:1]]].
>>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>>> *test/sim/GNU - Python Standard Library (2001).rar*
>>>
>>> But another one, the *only one*, produce:
>>>
>>> [fsimilar] ## Similar items
>>>  map[Similars:[{(eBook) GNU - Python Standard Library 2001 .pdf 1
>>> test/sim/ 15408562819203262167 8 1} {GNU - 2001 - Python Standard Library
>>> .pdf 1 test/sim/ 6184610222622303958 0 1} {GNU - Python Standard Library
>>> (2001) .rar 1 test/sim/ 6184610222622303958 0 1} {Python Standard Library
>>> .zip 1 test/sim/ 6175699711939618002 11 1}]].
>>> *test/sim/(eBook) GNU - Python Standard Library 2001.pdf*
>>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>>> *test/sim/GNU - Python Standard Library (2001).rar*
>>> *test/sim/Python Standard Library.zip*
>>>
>>> which is what I actually want.
>>>
>>> The rest of the following output are exactly the same across all three
>>> machines:
>>>
>>> $ go version
>>> go version go1.8.1 linux/amd64
>>>
>>> $ lsb_release -a
>>> No LSB modules are available.
>>> 

Re: [go-nuts] Help! Same code, different results

[Egon]

Try to find the first place where the processes diverge:

1. maybe find lists files in different order
2. maybe something read input does things in different order
3. maybe some processing uses maps --> hence random order
4. etc...

(of course run with -race, if you already haven't)

On Friday, 25 August 2017 21:56:29 UTC+3, Tong Sun wrote:
>
>
> Update, 
>
>
> On Fri, Aug 25, 2017 at 11:39 AM, Tong Sun  > wrote:
>
>> Hi, 
>>
>> I'm experiencing a *very very* strange problem now -- the same Go code 
>> is producing different results *for me*. 
>> I'm not kidding, I can't believe that myself, so I've spent *the past 
>> few days* going back and forth to verify everything. 
>> Now, after all these days, the only conclusion that I can make is, albeit 
>> how bazzard it is, same code, different results. 
>>
>> Can someone verify for me what you get please? 
>>
>> go get github.com/go-dedup/fsimilar
>>
>> then 
>>
>> cd go-dedup/fsimilar
>> go build
>> find test/sim -type f | ./fsimilar -i -d 12 -vv 
>>
>> and tell me what's the last output that you got please. 
>>
>> The problem is that *two *of my machines produce:
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - 
>> 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU 
>> - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/ 
>> Hash:6184610222622303958 Dist:0 SizeRef:1]]].
>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>> *test/sim/GNU - Python Standard Library (2001).rar*
>>
>> But another one, the *only one*, produce:
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[{(eBook) GNU - Python Standard Library 2001 .pdf 1 
>> test/sim/ 15408562819203262167 8 1} {GNU - 2001 - Python Standard Library 
>> .pdf 1 test/sim/ 6184610222622303958 0 1} {GNU - Python Standard Library 
>> (2001) .rar 1 test/sim/ 6184610222622303958 0 1} {Python Standard Library 
>> .zip 1 test/sim/ 6175699711939618002 11 1}]].
>> *test/sim/(eBook) GNU - Python Standard Library 2001.pdf*
>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>> *test/sim/GNU - Python Standard Library (2001).rar*
>> *test/sim/Python Standard Library.zip*
>>
>> which is what I actually want. 
>>
>> The rest of the following output are exactly the same across all three 
>> machines:
>>
>> $ go version 
>> go version go1.8.1 linux/amd64
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 17.04
>> Release:17.04
>> Codename:   zesty
>>
>> $ git status 
>> On branch master
>> Your branch is up-to-date with 'origin/master'.
>> nothing to commit, working tree clean
>>
>>
> - all the original source on three machines are pulled from the same git, 
> with same status.
> - I copied the bad code into good machine, and compared the two folders, 
> and files are the same
> - I ran the bad code in good machine, and the result is the bad code 
> works in the good machine. 
> - I copied the good code into bad machine, and the result is good code 
> doesn't work in bad machine any more. 
>
> Adding *all these things* up *I'm sure the code are the same *-- the only 
> different is the machine/build environment. 
>
> I installed from 
> https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz to both 
> machines. and Now both machines have go1.8.3:
>
> $ type go 
> go is hashed (/opt/bin/go)
>
> $ go version 
> go version go1.8.3 linux/amd64
>
>
> And having updgraded `github.com/fatih/structs` 
>  on the good machine, the following is 
> no longer an issue any more. 
>
> Oh, I do get one difference to illustrate how strange things are -- for 
>> the same code of:
>>
>> verbose(2, "## Similar items\n *%v*.", m)
>>
>> The working machine produces (last two line):
>>
>> [fsimilar] ## Similar items
>>  map[Similars:*[{*Improve Soccer Shooting Technique .mp4 10043873 ./Try 
>> These Soccer Drills/ 1808297800170271 0 10043873} {Improve Soccer 
>> Shooting Technique .mp4 10043873 ./Top Soccer Training Videos/ 
>> 1808297800170271 0 10043873}]].
>> [fsimilar] ## Similar items
>>  map[Similars:*[{*Soccer Drills For Youth .mp4 11650500 ./Youth Soccer 
>> Training Drills/ 18062776733066936110 0 11650500} {Soccer Drills For Youth 
>> .mp4 11650500 ./Top Soccer Training Videos/ 18062776733066936110 0 
>> 11650500}]].
>>
>>
>> while the machine with incorrect result produces (last two line):
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[*map*[Ext:.mp4 Size:10043873 Dir:./Try These Soccer 
>> Drills/ Hash:1808297800170271 Dist:0 SizeRef:10043873 Name:Improve 
>> Soccer Shooting Technique] map[Size:10043873 Dir:./Top Soccer Training 
>> Videos/ Hash:1808297800170271 Dist:0 SizeRef:10043873 Name:Improve 
>> Soccer Shooting Technique Ext:.mp4]]].
>> [fsimilar] ## Similar items
>>  map[Similars:[*map*[Dir:./Youth Soccer Training Drills/ 
>> Hash:18062776733066936110 Dist:0 

Re: [go-nuts] Help! Same code, different results

[mhhcbon]

[mh-cbon@pc2 rendez-vous] $ cd ../../go-dedup/fsimilar/
[mh-cbon@pc2 fsimilar] $ find test/sim -type f | ./fsimilar -i -d 12 -vv
[fsimilar]  n='GNU - 2001 - Python Standard Library', e='.pdf', s='1', d=
'test/sim/'
[fsimilar] +: Simhash of 55d4263ae1a6e6d6 added.
[fsimilar]  n='(eBook) GNU - Python Standard Library 2001', e='.pdf', s='1', 
d='test/sim/'
[fsimilar] =: Simhash of d5d6363ef9e6e6d7 ignored for 55d4263ae1a6e6d6 (8).
[fsimilar]  n='GNU - Python Standard Library (2001)', e='.rar', s='1', d=
'test/sim/'
[fsimilar] =: Simhash of 55d4263ae1a6e6d6 ignored for 55d4263ae1a6e6d6 (0).
[fsimilar]  n='Python Standard Library', e='.zip', s='1', d='test/sim/'
[fsimilar] =: Simhash of 55b47e2af1a4a4d2 ignored for 55d4263ae1a6e6d6 (11).
[fsimilar]  n='Audio Book - The Grey Coloured Bunnie', e='.mp3', s='1', d=
'test/sim/'
[fsimilar] +: Simhash of f8fde9fe7f7dbd5e added.
[fsimilar]  n='PopupTest', e='.java', s='1', d='test/sim/'
[fsimilar] +: Simhash of a0d9070f13c20979 added.
[fsimilar]  n='LayoutTest', e='.java', s='1', d='test/sim/'
[fsimilar] +: Simhash of 37299e9d4e277b87 added.
[fsimilar]  n='ColoredGrayBunny', e='.ogg', s='1', d='test/sim/'
[fsimilar] +: Simhash of 25eade3cd3db679c added.
[fsimilar] ## Similar items
 map[Similars:[map[Ext:.pdf Size:1 Dir:test/sim/ Hash:6184610222622303958 
Dist:0 SizeRef:1 Name:GNU - 2001 - Python Standard Library] map[Size:1 Dir:
test/sim/ Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - Python 
Standard Library (2001) Ext:.rar]]].
test/sim/GNU - 2001 - Python Standard Library.pdf
test/sim/GNU - Python Standard Library (2001).rar


[mh-cbon@pc2 fsimilar] $ go version
go version go1.8 linux/amd64
[mh-cbon@pc2 fsimilar] $ go env
GOARCH="amd64"
GOBIN="/home/mh-cbon/gow/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/mh-cbon/gow"
GORACE=""
GOROOT="/home/mh-cbon/.gvm/gos/go1.8"
GOTOOLDIR="/home/mh-cbon/.gvm/gos/go1.8/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build580933895=/tmp/go-build 
-gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
PKG_CONFIG="pkg-config"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
[mh-cbon@pc2 fsimilar] $ git log -n 1
commit 10c9f3f50da4f00f7fd874c24aa7c7787dcf275e (HEAD -> master, origin/
master, origin/HEAD)
Author: Tong Sun 
Date:   Thu Aug 24 00:36:37 2017 -0400

- [+] add FileT.Similarity()
[mh-cbon@pc2 fsimilar] $

hth


On Friday, August 25, 2017 at 8:56:29 PM UTC+2, Tong Sun wrote:
>
>
> Update, 
>
>
> On Fri, Aug 25, 2017 at 11:39 AM, Tong Sun  > wrote:
>
>> Hi, 
>>
>> I'm experiencing a *very very* strange problem now -- the same Go code 
>> is producing different results *for me*. 
>> I'm not kidding, I can't believe that myself, so I've spent *the past 
>> few days* going back and forth to verify everything. 
>> Now, after all these days, the only conclusion that I can make is, albeit 
>> how bazzard it is, same code, different results. 
>>
>> Can someone verify for me what you get please? 
>>
>> go get github.com/go-dedup/fsimilar
>>
>> then 
>>
>> cd go-dedup/fsimilar
>> go build
>> find test/sim -type f | ./fsimilar -i -d 12 -vv 
>>
>> and tell me what's the last output that you got please. 
>>
>> The problem is that *two *of my machines produce:
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - 
>> 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU 
>> - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/ 
>> Hash:6184610222622303958 Dist:0 SizeRef:1]]].
>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>> *test/sim/GNU - Python Standard Library (2001).rar*
>>
>> But another one, the *only one*, produce:
>>
>> [fsimilar] ## Similar items
>>  map[Similars:[{(eBook) GNU - Python Standard Library 2001 .pdf 1 
>> test/sim/ 15408562819203262167 8 1} {GNU - 2001 - Python Standard Library 
>> .pdf 1 test/sim/ 6184610222622303958 0 1} {GNU - Python Standard Library 
>> (2001) .rar 1 test/sim/ 6184610222622303958 0 1} {Python Standard Library 
>> .zip 1 test/sim/ 6175699711939618002 11 1}]].
>> *test/sim/(eBook) GNU - Python Standard Library 2001.pdf*
>> *test/sim/GNU - 2001 - Python Standard Library.pdf*
>> *test/sim/GNU - Python Standard Library (2001).rar*
>> *test/sim/Python Standard Library.zip*
>>
>> which is what I actually want. 
>>
>> The rest of the following output are exactly the same across all three 
>> machines:
>>
>> $ go version 
>> go version go1.8.1 linux/amd64
>>
>> $ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:Ubuntu 17.04
>> Release:17.04
>> Codename:   zesty
>>
>> $ git status 
>> On branch master
>> Your branch is up-to-date with 'origin/master'.
>> nothing to commit, working tree clean
>>
>>
> - all the original source on three machines are pulled from 

[go-nuts] https://golang.org/pkg/builtin/#append

[mhhcbon]

looks broken here 

__

File builtin builtin 

/src/builtin/builtin.go:88:11: expected type, found '=' (and 1 more errors) 

-- 
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] Generics and readability

[Jesper Louis Andersen]

On Thu, Aug 24, 2017 at 5:14 PM  wrote:


>  func (r genType1) f(x, y genType2) (z getType2, err
> error)
>
>
In a language such as OCaml, you would define `f` as:

let f r (x, y) = ...

And the system would infer the type of `f` automatically. In your case it
would probably infer something like

val f : 'a -> 'b -> 'b -> ('b * error)

which is really something along the lines of

forall 'a .
forall 'b .
val f : 'a -> 'b -> 'b -> ('b * error)

As an aside, people often say `alpha` rather than `'a` and `beta` rather
than `'b` when speaking the type out loud.

As another aside: if you don't get the above, you wouldn't have been able
to pass the first course at my university back in the day (around 2000). I
think we can expect people who become proficient programmers over time to
eventually grasp an introductory programming course. Mind you, many
languages aside from Go defines the type-level abstraction, so it is hardly
expected to be "new" anymore to a great large set of people.

Personally, I find pointer handling far more complex than the above :)

-- 
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] Getting the current process signal disposition

[adam.azarchs via golang-nuts]

TL;DR it would be nice if there were a public API to find the current 
signal disposition of your process.  The runtime already stores that 
information in runtime.sigtable, but doesn't expose it.

I ran into a gotcha with handling SIGHUP the other day.  I need to handle 
SIGHUP in order to shut down gracefully.  However, nohup works by setting 
the process's signal disposition to ignore SIGHUP, and adding a handler 
un-ignores the signal, meaning the process shuts down when it shouldn't.  
Figuring out whether it was ignored, however, proved unpleasantly 
difficult. I know this would be straightforward enough to solve with cgo, 
but that opens us up to deployment difficulties for customers with older 
libc.  It's a bit aggravating that the runtime already has the information 
I want but doesn't give me a way to see it.  For the moment I'm just making 
the syscall but this seems like information the os/signal package should 
expose, for people who for example want to know what signal.Reset is 
resetting things *to*.

-- 
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] Help! Same code, different results

[Tong Sun]

On Fri, Aug 25, 2017 at 12:09 PM, Konstantin Khomoutov 
wrote:

> On Fri, Aug 25, 2017 at 08:39:29AM -0700, Tong Sun wrote:
>
> > I'm experiencing a *very very* strange problem now -- the same Go code is
> > producing different results *for me*.
> [...]
> > Can someone verify for me what you get please?
> >
> > go get github.com/go-dedup/fsimilar
> >
> > then
> >
> > cd go-dedup/fsimilar
> > go build
> > find test/sim -type f | ./fsimilar -i -d 12 -vv
> >
> > and tell me what's the last output that you got please.
> >
> > The problem is that *two *of my machines produce:
> >
> > [fsimilar] ## Similar items
> >  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU -
> > 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/]
> map[Name:GNU
> > - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/
> > Hash:6184610222622303958 Dist:0 SizeRef:1]]].
> > *test/sim/GNU - 2001 - Python Standard Library.pdf*
> > *test/sim/GNU - Python Standard Library (2001).rar*
> >
> > But another one, the *only one*, produce:
> [...]
>
> Two quick points:
>
> * What happens if you copy the "working" binary to the "wrong" machine
>   and run it there?
>
>   Does it work?
>

Ah, good idea. Previously I was copying the bad code into good machine, and
the result is the bad code works in the good machine.

Now I copy the good code into bad machine, and the result is good code
doesn't work in bad machine any more.

Giving that the original source is pulled from the same git, with same
status, adding these *three things* up *I'm sure the code are the same now*
-- the only different is the machine.



>   I mean, you should rule out possible inconsistencies with build
>   systems.  This means both Go and all the graph of the libraries
>   your project uses.  If you're building on each machine, try doing
>   clean-room building.  This means freshly cloning the Go source code
>   of, say, the 1.8 release branch and building it.  Then copying over
>   the whole hierarchy of the whole branch of the dependencies from the
>   "working" machine into a new directory which must be a Go workspace.
>   Then building there.
>

All three machines are using the same golang ubuntu packages:

$ apt-cache policy golang-1.8-go
golang-1.8-go:
  Installed: 1.8.1-1ubuntu1
  Candidate: 1.8.1-1ubuntu1

I'll try download go binary from go source next.


> * This bit [1] smells bad IMO.
>
>   From the quick glance I failed to see where it's used but
>   why it's there?  What happens if you seed PRNG with a constant?
>
> 1. https://github.com/go-dedup/fsimilar/blob/master/fsimilarCLICmd.go#L70
>

Yeah, you are right, it is not used at all. It is copied there for future
features that I haven't put in yet.
So we can rule that out.



Can someone try it out for me and see what you got please?

-- 
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] Convert grid of colors to SVG

[andrey mirtchovski]

I'm sorry, I assumed that you were looking for an SVG library.

I think putting your code on bitbucket or elsewhere is a good idea.

On Fri, Aug 25, 2017 at 11:18 AM,   wrote:
> Thanks Andrey,
> SVGO didn't seem to include that particular functionality. Maybe I just
> didn't look carefully enough?
>
> On Friday, August 25, 2017 at 12:32:25 PM UTC-4, andrey mirtchovski wrote:
>>
>> There's svgo: https://github.com/ajstarks/svgo
>>
>> When in doubt, put your code out there :)
>>
> --
> 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] Convert grid of colors to SVG

[steve_bagwell]

Thanks Andrey,
SVGO didn't seem to include that particular functionality. Maybe I just 
didn't look carefully enough?

On Friday, August 25, 2017 at 12:32:25 PM UTC-4, andrey mirtchovski wrote:
>
> There's svgo: https://github.com/ajstarks/svgo 
>
> When in doubt, put your code out there :) 
>
>

-- 
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] GemX: Generics For Go, Yet Again.

[Ahmed (OneOfOne) W.]

GenX  is a project I've been working on 
and I'd like some feedback (code documentation and tests are lacking atm, 
working on that).
I designed it to be as simple as possible while being able to handle 
advanced scenarios.

For example, if the input file/package only uses one type (aka 
`interface{}`) you don't have to change anything.

However you can target types, remove functions/types and all kinds of other 
things based on what you need.

Advanced example does different things based on the passed types:

   - https://github.com/OneOfOne/cmap/blob/master/cmap_if_string.go
   - https://github.com/OneOfOne/cmap/blob/master/cmap_if_other.go
   
Features
   
   - It can be *easily* used with go generate, from the command line or as 
   a library.
   - cmd/genx Uses local files, packages, and optionally uses go get (with 
   the -get flag) if the remote package doesn't exist.
   - You can rewrite, remove and change pretty much everything.
   - Allows you to merge a package of multiple files into a single one.
   - *Safely* remove functions and struct fields.
   - Automatically passes all code through x/tools/imports (aka goimports).
   - If you intend on generating files in the same package, you may add // 
   +build genx to your template(s).
   - Transparently handles genny 's 
   generic.Type.
   - Supports a few seeds 
   .
   - Adds build tags based on the types you pass, so you can target specifc 
   types (ex: // +build genx_t_string or // +build genx_vt_builtin )
   - Automatically handles nil returns, will return the zero value of the 
   type.
   - Doesn't need modifying the source package if there's only one type 
   involved.



-- 
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: [golang-dev] Go 1.9 is released

[Ian Lance Taylor]

On Fri, Aug 25, 2017 at 1:53 AM, Steven Hartland  wrote:
>
> One thing I've noticed, having read through the blog post and release notes,
> is a mention of the issue with the netpoller is surprisingly absent.
>
> This issue has bitten us quite a bit, only tracked it down this week, so
> would have expected to see this one to mentioned given it can and does cause
> TCP connections from the runtime to fail randomly; something worth adding?

In general we don't mention every bug fix in the release notes, and
this one is fairly uncommon, and I think mainly occurs when trying to
connect to a TCP port on which nothing is listening.  That said, if
you want to send in a patch for the release notes, that would be fine.
Thanks.

Ian

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Convert grid of colors to SVG

[andrey mirtchovski]

There's svgo: https://github.com/ajstarks/svgo

When in doubt, put your code out there :)

On Fri, Aug 25, 2017 at 9:37 AM,   wrote:
> I've been experimenting with Go recently, having been more of a Python
> programmer.
> As an exercise, I've written a Go program that creates simple SVG xml based
> on a 2-dimensional grid of colors.  I'm wondering if that's something worth
> putting up on Bitbucket or is there already a repo out there that does it?
> I haven't found one so far.
>
> --
> 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] Convert grid of colors to SVG

[steve_bagwell]

I've been experimenting with Go recently, having been more of a Python 
programmer.
As an exercise, I've written a Go program that creates simple SVG xml based 
on a 2-dimensional grid of colors.  I'm wondering if that's something worth 
putting up on Bitbucket or is there already a repo out there that does it? 
 I haven't found one so far.

-- 
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] Help! Same code, different results

[Konstantin Khomoutov]

On Fri, Aug 25, 2017 at 08:39:29AM -0700, Tong Sun wrote:

> I'm experiencing a *very very* strange problem now -- the same Go code is 
> producing different results *for me*. 
[...]
> Can someone verify for me what you get please? 
> 
> go get github.com/go-dedup/fsimilar
> 
> then 
> 
> cd go-dedup/fsimilar
> go build
> find test/sim -type f | ./fsimilar -i -d 12 -vv 
> 
> and tell me what's the last output that you got please. 
> 
> The problem is that *two *of my machines produce:
> 
> [fsimilar] ## Similar items
>  map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - 
> 2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU 
> - Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/ 
> Hash:6184610222622303958 Dist:0 SizeRef:1]]].
> *test/sim/GNU - 2001 - Python Standard Library.pdf*
> *test/sim/GNU - Python Standard Library (2001).rar*
> 
> But another one, the *only one*, produce:
[...]

Two quick points:

* What happens if you copy the "working" binary to the "wrong" machine
  and run it there?

  Does it work?

  I mean, you should rule out possible inconsistencies with build
  systems.  This means both Go and all the graph of the libraries
  your project uses.  If you're building on each machine, try doing
  clean-room building.  This means freshly cloning the Go source code
  of, say, the 1.8 release branch and building it.  Then copying over
  the whole hierarchy of the whole branch of the dependencies from the
  "working" machine into a new directory which must be a Go workspace.
  Then building there.

* This bit [1] smells bad IMO.
  
  From the quick glance I failed to see where it's used but
  why it's there?  What happens if you seed PRNG with a constant?

1. https://github.com/go-dedup/fsimilar/blob/master/fsimilarCLICmd.go#L70

-- 
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] Help! Same code, different results

[Tong Sun]

Hi, 

I'm experiencing a *very very* strange problem now -- the same Go code is 
producing different results *for me*. 
I'm not kidding, I can't believe that myself, so I've spent *the past few 
days* going back and forth to verify everything. 
Now, after all these days, the only conclusion that I can make is, albeit 
how bazzard it is, same code, different results. 

Can someone verify for me what you get please? 

go get github.com/go-dedup/fsimilar

then 

cd go-dedup/fsimilar
go build
find test/sim -type f | ./fsimilar -i -d 12 -vv 

and tell me what's the last output that you got please. 

The problem is that *two *of my machines produce:

[fsimilar] ## Similar items
 map[Similars:[map[Hash:6184610222622303958 Dist:0 SizeRef:1 Name:GNU - 
2001 - Python Standard Library Ext:.pdf Size:1 Dir:test/sim/] map[Name:GNU 
- Python Standard Library (2001) Ext:.rar Size:1 Dir:test/sim/ 
Hash:6184610222622303958 Dist:0 SizeRef:1]]].
*test/sim/GNU - 2001 - Python Standard Library.pdf*
*test/sim/GNU - Python Standard Library (2001).rar*

But another one, the *only one*, produce:

[fsimilar] ## Similar items
 map[Similars:[{(eBook) GNU - Python Standard Library 2001 .pdf 1 test/sim/ 
15408562819203262167 8 1} {GNU - 2001 - Python Standard Library .pdf 1 
test/sim/ 6184610222622303958 0 1} {GNU - Python Standard Library (2001) 
.rar 1 test/sim/ 6184610222622303958 0 1} {Python Standard Library .zip 1 
test/sim/ 6175699711939618002 11 1}]].
*test/sim/(eBook) GNU - Python Standard Library 2001.pdf*
*test/sim/GNU - 2001 - Python Standard Library.pdf*
*test/sim/GNU - Python Standard Library (2001).rar*
*test/sim/Python Standard Library.zip*

which is what I actually want. 

The rest of the following output are exactly the same across all three 
machines:

$ go version 
go version go1.8.1 linux/amd64

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 17.04
Release:17.04
Codename:   zesty

$ git status 
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

I am afraid that you will get the first result. Please let me know. 

Oh, I do get one difference to illustrate how strange things are -- for the 
same code of:

verbose(2, "## Similar items\n *%v*.", m)

The working machine produces (last two line):

[fsimilar] ## Similar items
 map[Similars:*[{*Improve Soccer Shooting Technique .mp4 10043873 ./Try 
These Soccer Drills/ 1808297800170271 0 10043873} {Improve Soccer 
Shooting Technique .mp4 10043873 ./Top Soccer Training Videos/ 
1808297800170271 0 10043873}]].
[fsimilar] ## Similar items
 map[Similars:*[{*Soccer Drills For Youth .mp4 11650500 ./Youth Soccer 
Training Drills/ 18062776733066936110 0 11650500} {Soccer Drills For Youth 
.mp4 11650500 ./Top Soccer Training Videos/ 18062776733066936110 0 
11650500}]].


while the machine with incorrect result produces (last two line):

[fsimilar] ## Similar items
 map[Similars:[*map*[Ext:.mp4 Size:10043873 Dir:./Try These Soccer Drills/ 
Hash:1808297800170271 Dist:0 SizeRef:10043873 Name:Improve Soccer 
Shooting Technique] map[Size:10043873 Dir:./Top Soccer Training Videos/ 
Hash:1808297800170271 Dist:0 SizeRef:10043873 Name:Improve Soccer 
Shooting Technique Ext:.mp4]]].
[fsimilar] ## Similar items
 map[Similars:[*map*[Dir:./Youth Soccer Training Drills/ 
Hash:18062776733066936110 Dist:0 SizeRef:11650500 Name:Soccer Drills For 
Youth Ext:.mp4 Size:11650500] map[SizeRef:11650500 Name:Soccer Drills For 
Youth Ext:.mp4 Size:11650500 Dir:./Top Soccer Training Videos/ 
Hash:18062776733066936110 Dist:0]]].


even though the code is the same and their `go version` reported the same 
as well. 

The command to produce above is, 

./fsimilar -i test/test1.lst -S -d 6 -vv 2> /tmp/log

Then compare the two logs. 

I've spent *the past few days* to verify & double check everything, and now 
my mind is blocked and I'm out of ideas. 
Somebody help, Please. 

THANKS!!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Go 1.9 is released

[Rich]

One liner for installing on Linux. You can change the URL in the curl for 
other OS such as Mac, or any Unix like OS:

cd $GOROOT;cd ..;curl 
https://storage.googleapis.com/golang/go1.9.linux-amd64.tar.gz | sudo tar 
zxvf -;cd;/usr/local/go/bin/go version

if you don't have GOROOT Set:
cd /usr/local;curl 
https://storage.googleapis.com/golang/go1.9.linux-amd64.tar.gz | sudo tar 
zxvf -;cd;/usr/local/go/bin/go version

That installs into /usr/local/go.  


On Thursday, August 24, 2017 at 6:44:25 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.9
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.9" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.9
>
> 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 1.9 is released

[Rich]


One Liner for installing on Linux / Mac or other Unix like OS: (well almost)

1. Become root
2. cd /usr/local
run this command:

curl https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz 2> 
/dev/null | tar zxvf -

Just make sure you change the URL to curl for the OS version you're working 
on. Above is for Mac, on linux I installed it like this:

cd $GOROOT;cd ..;curl 
https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz | sudo tar 
zxvf -

On Thursday, August 24, 2017 at 6:44:25 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.9
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.9" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.9
>
> 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 1.9 is released

[Rich]


One Liner for installing on Linux / Mac or other Unix like OS: (well almost)

1. Become root
2. cd /usr/local
run this command:

curl https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz 2> 
/dev/null | tar zxvf -

Just make sure you change the URL to curl for the OS version you're working 
on. Above is for Mac, on linux I installed it like this:

cd $GOROOT;cd ..;curl 
https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz | sudo tar 
zxvf

On Thursday, August 24, 2017 at 6:44:25 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.9
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.9" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.9
>
> 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 1.9 is released

[Rich]



9:20 AM (less than a minute ago)


One Liner for installing on Linux / Mac or other Unix like OS: (well almost)

1. Become root
2. cd /usr/local
run this command:

curl https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz 2> 
/dev/null | tar zxvf -

Just make sure you change the URL to curl for the OS version you're working 
on. Above is for Mac, on linux I installed it like this:

cd $GOROOT;cd ..;curl 
https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz | sudo tar 
zxvf -

On Thursday, August 24, 2017 at 6:44:25 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.9
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.9" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.9
>
> 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 1.9 is released

[Rich]

One Liner for installing on Linux / Mac or other Unix like OS: (well almost)

1. Become root
2. cd /usr/local
run this command:

curl https://storage.googleapis.com/golang/go1.9.darwin-amd64.tar.gz 2> 
/dev/null | tar zxvf -



On Thursday, August 24, 2017 at 6:44:25 PM UTC-4, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We just released Go 1.9.
>
> You can read the announcement blog post here:
>   https://blog.golang.org/go1.9
>
> You can download binary and source distributions from our download page:
>   https://golang.org/dl/
>
> To compile from source using a Git checkout, update to the release with 
> "git checkout go1.9" and build as usual.
>
> To find out what has changed, read the release notes:
>   https://golang.org/doc/go1.9
>
> 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.

Re: [go-nuts] Re: Go 1.9 is released

[Igor Maznitsa]

>>The package search [1] turns up this file is provided by libc6 (for 
arm64). 
exactly, I just have downloaded arm64 distributive instead of amd64 :) , 
amd64 works well, I made the error because 
https://storage.googleapis.com/golang/ doesn't contain 1.9 and I have to 
load it manually

-- 
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.9 is released

[ojucie]

Thank you, guys. Good job.

-- 
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 1.9 is released

[Konstantin Khomoutov]

On Fri, Aug 25, 2017 at 02:05:52AM -0700, Igor Maznitsa wrote:

> and why the SDK  is not presented in the list 
> https://storage.googleapis.com/golang/ ?
> also under Ubuntu 16.04 LTS I have some error for any attempt to start Go 
> 1.9 from downloaded SDK : 
> /lib/ld-linux-aarch64.so.1: No such file or directory
> I don't have any such error with the 1.8.3, is it normal situation now?

The package search [1] turns up this file is provided by libc6 (for arm64).

So do you really using arm64 (not amd64) and have libc6 installed?
(I doubt the second as this package should be essential on
Debian-derived distros but the former might be the culprit.

1.  
https://packages.ubuntu.com/search?searchon=contents=ld-linux-aarch64.so.1==xenial=any

-- 
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: Generics and readability

[mhhcbon]

mh, what do you think of this quote ? Not to reject the whole work, 
just an example i stumble upon.

___

Note that type deduction requires types to be identical. This is stronger 
than the usual requirement when calling a function, namely that the types 
are assignable.


func [T] Find(s []T, e T) bool
type E interface{}
var f1 = 0
// Below does not compile.  The first argument means that T is
// deduced as E. f1 is type int, not E. f1 is assignable to
// E, but not identical to it.
var f2 = Find([]E{f1}, f1)
// Below does compile. Explicit type specification for Find
// means that type deduction is not performed.
var f3 = Find[E]([]E{f1}, f1)

___


Stupid remark, in "Note that type deduction requires types to be 
identical", if the type must be identical, 
there is no mechanism for type deduction that can take place.

>From human point of view,
[]interface is as good as []int to store/receive ...int


On Friday, August 25, 2017 at 1:06:44 PM UTC+2, Henrik Johansson wrote:
>
> Ah yes unfortunate that Ians proposal was rejected.
>
> fre 25 aug. 2017 kl 10:39 skrev 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com >:
>
>> Maybe a loaded question but what is the goal of this thread? Is it to 
>> establish whether or not generics impact readability? In that case it 
>> should get a lot more civil and charitable on both sides.
>>
>> Anyway, my take on that: The examples mentioned, in a very real way, are 
>> not really suitable to discuss that question. Any readability impact comes 
>> not so much from simple declarations, but from a) how frequent 
>> type-parameterized objects are going to be and b) how often we can omit the 
>> type-parameteres. The issues are things like parameterized type-parameters 
>> (today this example 
>>  flew 
>> through my twitter stream, to illustrate the point) and extra layers of 
>> abstraction (like using a Map instead of a 
>> map[string]int).
>>
>> Basically, we have three opposing forces: 1) How powerful the generics 
>> implementation is, that is what are the things that can be parameterized, 
>> 2) How powerful type-inference is for them, that is in which specific 
>> circumstances types can be omitted (this is the vital "readability" part) 
>> and 3) How simple the description of them is, that is how easy is it to 
>> understand failed type-checks to the programmer and how much space would 
>> they take up in the spec and/or implementation.
>>
>> Currently, Go *mostly* has 1 near zero (it is a little positive due to 
>> the existence of map, [], chan… and append/copy/…), in preference of 2 and 
>> 3. Most people agree, that 1 should get a little more love though. It's 
>> easy to come up with syntax or semantics that make 1 large, but the issue 
>> is, that while we want to increase 1, we don't just want to neglect 2 and 3.
>>
>> Most languages with powerful generics will also include a lot of 
>> machinery for 2, that is a complicated type-inference mechanism. Because 
>> it's so complicated, they will mostly omit 3, that is they will not specify 
>> how exactly it works and leave that up to the implementation, giving them 
>> the flexibility to tune the intelligence over time. Most of them (*cough* 
>> C++ 
>> 
>>  
>> *cough*) also completely fail to provide meaningful error messages for even 
>> reasonably simple failures.
>>
>> Now, it's easy to just write down *some* generic (or not generic) code to 
>> illustrate some level of readability. But to actually see the effects, a 
>> lot more and realistic code is needed and we *need* to talk about 2 and 3. 
>> An incredibly good example for how to discuss these is Ian's Proposal 
>> for type parameters 
>> .
>>  
>> It gives a detailed description of the power, the type-inference mechanism 
>> and the complexity of implementation. AIUI, it failed because of 3.
>>
>> Not every message or opinion about this, of course, needs this level of 
>> detail. But just ignoring the complexity is oversimplifying and doesn't do 
>> your position a lot of favor.
>> A better way to talk about readability would be, to take a real piece of 
>> code that you'd like to write generically (or predict that people would 
>> write), take one or two of the existing (declined) proposals and write your 
>> code down assuming it where implemented. The advantage is, that the 
>> proposals usually are detailed enough to meaningfully talk about the 
>> tradeoffs involved and to be sure that "the compiler can infer that" isn't 
>> just hand-waved.
>>
>> But Hot-Takes don't really help anyone.
>>
>> On Fri, Aug 25, 2017 at 10:11 AM, Egon  
>> wrote:
>>
>>> package tree
>>>
>>> type Node<$Entry> 

[go-nuts] Re: Generics and readability

[mhhcbon]

In first example Value can not do Less, its Entry, Entry has not been 
defined yet, its nothing.
Unless you introduce a Lesser interface and specify Node<$Entry:Lesser>

Given that specific example this notation looks pretty heavy, 
and even worse if d that be 
As this is all scoped into a type definition, why this prefix "node." ?
Also there s node everywhere, its confusing.


I m confused by the second example, the package declaration seems to 
declare what should be parametric.
It looks weird to import from another package.
Entry generic type is an interface, isn it ?


apart from this, why is side a double pointer ?


On Friday, August 25, 2017 at 10:11:11 AM UTC+2, Egon wrote:
>
> package tree
>
> type Node<$Entry> struct {
> Value $Entry
> Left  *Node<$Entry>
> Right *Node<$Entry>
> }
>
> func (node *Node) Insert(value node.$Entry) {
> var side **Node
> if node.Value.Less(value) {
> side = 
> } else {
> side = 
> } 
>
> if *side == nil {
> *side = {Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
> --
>
> package tree
>
> type Entry generic {
> Less(Entry) bool
> }
>
> type Node struct {
> Value Entry
> Left  *Node
> Right *Node
> }
>
> func (node *Node) Insert(value Entry) {
> var side *Node
> if node.Value.Less(value) {
> side = 
> } else {
> side = 
> } 
>
> if *side == nil {
> *side = {Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
>
> On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>>
>> Why would you put generics on a method ?
>>
>> The syntax you demonstrate is horrible, indeed.
>>
>> what if generics are type related
>>
>> type notFinal struct {
>>p1 
>>p2 
>> }
>>
>> func (n notFinal) whatever(in ) string {
>>return fmt.Sprintf(in) // anything to interface{}, works.
>> }
>>
>> type Final notFinal
>>
>> Final.whatever(1) // "1"
>>
>> //notFinal not instantiable, not type assertable
>>
>>
>>
>> Or func related
>>
>> type notFinal func(in ) string
>>
>> func Final notFinal
>>
>> Final(1) // "1"
>>
>>
>> That said, ultimately, the more the syntax is parametrized the more 
>> complex it become. when there are many func signature as you demonstrate, 
>> it will get worse.
>>
>> Named type might help, could be vetted too ?
>>
>> Also 
>> none of this is as powerful as code gen.
>> None of those examples are better than interface{}.
>>
>> On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>>>
>>> A lot of people like Go because code is very readable even for beginners.
>>>
>>> func f(x, y int)
>>>
>>> f is a function that receives x and y as int parameters, returning 
>>> nothing. Simple enough.
>>>
>>> func f(x, y int) int
>>>
>>> f is a function that receives x and y as int parameters, returning yet 
>>> another int. Fine.
>>>
>>> func f(x, y int) (z int, err error)
>>>
>>> f is a function that receives x and y as int parameters, returning two 
>>> values: a first int, that we name z and an error named err. A little bit 
>>> weird, but ok.
>>>
>>> func (r MyType) f(x, y int) (z int, err error)
>>>
>>> f is a method for a value of type MyType, henceforth named r, that 
>>> receives x and y as int parameters, returning two values: a first int, that 
>>> we name z and an error named err. Definitely not so simple.
>>>
>>>  func (r genType1) f(x, y genType2) (z getType2, err 
>>> error)
>>>
>>> You must be kidding. STOP RIGHT THERE!
>>>
>>>

-- 
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: Generics and readability

[Henrik Johansson]

Ah yes unfortunate that Ians proposal was rejected.

fre 25 aug. 2017 kl 10:39 skrev 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> Maybe a loaded question but what is the goal of this thread? Is it to
> establish whether or not generics impact readability? In that case it
> should get a lot more civil and charitable on both sides.
>
> Anyway, my take on that: The examples mentioned, in a very real way, are
> not really suitable to discuss that question. Any readability impact comes
> not so much from simple declarations, but from a) how frequent
> type-parameterized objects are going to be and b) how often we can omit the
> type-parameteres. The issues are things like parameterized type-parameters
> (today this example
>  flew
> through my twitter stream, to illustrate the point) and extra layers of
> abstraction (like using a Map instead of a
> map[string]int).
>
> Basically, we have three opposing forces: 1) How powerful the generics
> implementation is, that is what are the things that can be parameterized,
> 2) How powerful type-inference is for them, that is in which specific
> circumstances types can be omitted (this is the vital "readability" part)
> and 3) How simple the description of them is, that is how easy is it to
> understand failed type-checks to the programmer and how much space would
> they take up in the spec and/or implementation.
>
> Currently, Go *mostly* has 1 near zero (it is a little positive due to the
> existence of map, [], chan… and append/copy/…), in preference of 2 and 3.
> Most people agree, that 1 should get a little more love though. It's easy
> to come up with syntax or semantics that make 1 large, but the issue is,
> that while we want to increase 1, we don't just want to neglect 2 and 3.
>
> Most languages with powerful generics will also include a lot of machinery
> for 2, that is a complicated type-inference mechanism. Because it's so
> complicated, they will mostly omit 3, that is they will not specify how
> exactly it works and leave that up to the implementation, giving them the
> flexibility to tune the intelligence over time. Most of them (*cough* C++
> 
> *cough*) also completely fail to provide meaningful error messages for even
> reasonably simple failures.
>
> Now, it's easy to just write down *some* generic (or not generic) code to
> illustrate some level of readability. But to actually see the effects, a
> lot more and realistic code is needed and we *need* to talk about 2 and 3.
> An incredibly good example for how to discuss these is Ian's Proposal for
> type parameters
> .
> It gives a detailed description of the power, the type-inference mechanism
> and the complexity of implementation. AIUI, it failed because of 3.
>
> Not every message or opinion about this, of course, needs this level of
> detail. But just ignoring the complexity is oversimplifying and doesn't do
> your position a lot of favor.
> A better way to talk about readability would be, to take a real piece of
> code that you'd like to write generically (or predict that people would
> write), take one or two of the existing (declined) proposals and write your
> code down assuming it where implemented. The advantage is, that the
> proposals usually are detailed enough to meaningfully talk about the
> tradeoffs involved and to be sure that "the compiler can infer that" isn't
> just hand-waved.
>
> But Hot-Takes don't really help anyone.
>
> On Fri, Aug 25, 2017 at 10:11 AM, Egon  wrote:
>
>> package tree
>>
>> type Node<$Entry> struct {
>> Value $Entry
>> Left  *Node<$Entry>
>> Right *Node<$Entry>
>> }
>>
>> func (node *Node) Insert(value node.$Entry) {
>> var side **Node
>> if node.Value.Less(value) {
>> side = 
>> } else {
>> side = 
>> }
>>
>> if *side == nil {
>> *side = {Value: value}
>> } else {
>> (*side).Insert(value)
>> }
>> }
>>
>> --
>>
>> package tree
>>
>> type Entry generic {
>> Less(Entry) bool
>> }
>>
>> type Node struct {
>> Value Entry
>> Left  *Node
>> Right *Node
>> }
>>
>> func (node *Node) Insert(value Entry) {
>> var side *Node
>> if node.Value.Less(value) {
>> side = 
>> } else {
>> side = 
>> }
>>
>> if *side == nil {
>> *side = {Value: value}
>> } else {
>> (*side).Insert(value)
>> }
>> }
>>
>>
>> On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>>>
>>> Why would you put generics on a method ?
>>>
>>> The syntax you demonstrate is horrible, indeed.
>>>
>>> what if generics are type related
>>>
>>> type notFinal struct {
>>>p1 
>>>p2 
>>> }
>>>
>>> func (n notFinal) whatever(in ) string {
>>>return fmt.Sprintf(in) // anything to interface{}, works.
>>> }
>>>
>>> type Final notFinal
>>>
>>> Final.whatever(1) // 

Re: [go-nuts] Should we stop using a global logger?

[Peter Mogensen]

On 2017-08-25 12:53, Henrik Johansson wrote:
> Yes it works ok we have done it as well but a common interface wouldbe
> convenient. Especially when opentracing whose Go libs seems to take off
> nicely with afaik a common interface. Logging seems even simpler.
> 
> I have started to use Zap pervasively and its typed API is very neat.

I did a survey involving basically every logger library I could find
some time ago and ended up concluding that non of them had an easy way
to do logging to systemd in the form "message" on stdout/stderr.
(where X is the syslog level).
So we ended up doing our own logging library. I don't think Zap was
around at the time.

Yeah... I know... The log15 author has a point. But I find the result
pretty useful.

/Peter

-- 
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] Should we stop using a global logger?

[Henrik Johansson]

Yes it works ok we have done it as well but a common interface wouldbe
convenient. Especially when opentracing whose Go libs seems to take off
nicely with afaik a common interface. Logging seems even simpler.

I have started to use Zap pervasively and its typed API is very neat.

fre 25 aug. 2017 kl 11:14 skrev Peter Mogensen :

>
>
> On 2017-08-25 10:45, Henrik Johansson wrote:
> > Me neither but it can be very neat occasionally.
> >
> > Agreed and it also applies fine things like Tracing.
> > But logger? If you change logger implementation you have to have a
> > wrapper or you have to change the type conversions everywhere.
>
> But isn't that a general problem - regardless of the specific question
> of this thread.
> I just keep logging concerns for the application. On the rare occasions
> logging from a library is useful, I provide an API to set a callback
> with a simple generic interface.
> Like SetLogger(func(int level, msg string))
> If rewriting to change logger implementation is intolerable to the
> application, the application could define its own interface to a logging
> abstraction.
>
> /Peter
>

-- 
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] Should we stop using a global logger?

[Peter Mogensen]

On 2017-08-25 10:45, Henrik Johansson wrote:
> Me neither but it can be very neat occasionally.
> 
> Agreed and it also applies fine things like Tracing.
> But logger? If you change logger implementation you have to have a
> wrapper or you have to change the type conversions everywhere.

But isn't that a general problem - regardless of the specific question
of this thread.
I just keep logging concerns for the application. On the rare occasions
logging from a library is useful, I provide an API to set a callback
with a simple generic interface.
Like SetLogger(func(int level, msg string))
If rewriting to change logger implementation is intolerable to the
application, the application could define its own interface to a logging
abstraction.

/Peter

-- 
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] Should we stop using a global logger?

[Tamás Gulácsi]

I use "func(...interface{}) error" as the log func interface - that's what 
go-kit/kit/log provides without an explicit interface.
Does not do much, easy to wrap into any logger but provides structural logging.
With closures, sub-loggers are possible, too.

-- 
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.9 is released

[Igor Maznitsa]

and why the SDK  is not presented in the list 
https://storage.googleapis.com/golang/ ?
also under Ubuntu 16.04 LTS I have some error for any attempt to start Go 
1.9 from downloaded SDK : 
*/lib/ld-linux-aarch64.so.1: No such file or directory*
I don't have any such error with the 1.8.3, is it normal situation now?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: [golang-dev] Go 1.9 is released

[Steven Hartland]

Thanks for everyone's hard work on this!

One thing I've noticed, having read through the blog post and release 
notes, is a mention of the issue with the netpoller 
 
is surprisingly absent.


This issue has bitten us quite a bit, only tracked it down 
 this week, 
so would have expected to see this one to mentioned given it can and 
does cause TCP connections from the runtime to fail randomly; something 
worth adding?


    Regards
    Steve

On 24/08/2017 23:43, Chris Broadfoot wrote:

Hello gophers,

We just released Go 1.9.

You can read the announcement blog post here:
https://blog.golang.org/go1.9

You can download binary and source distributions from our download page:
https://golang.org/dl/

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


To find out what has changed, read the release notes:
https://golang.org/doc/go1.9

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] Should we stop using a global logger?

[Henrik Johansson]

Me neither but it can be very neat occasionally.

Agreed and it also applies fine things like Tracing.
But logger? If you change logger implementation you have to have a wrapper
or you have to change the type conversions everywhere.
Maybe refactoring tools can help I guess but I miss a common interface for
logging. There was some promising work alas no consensus afaik.


fre 25 aug. 2017 kl 08:47 skrev Peter Mogensen :

>
>
> On 2017-08-25 08:31, Henrik Johansson wrote:
> > How do you code for storing a logger in context.Value? The same usual
> > issues with lacking a shared logger interface happens or did I miss
> > something neat?
> >
>
> I try not to do logging from libraries. So logging (and the logger
> interface) is specific to my application.
>
> Internally I would pass loggers as arguments, but using context.Context
> becomes relevant when building a middleware stack. So the application
> installs both the middleware creating the logger and the handler using
> it. (and they then both know the type).
> There can be other application specific request-scoped stuff you want to
> pass along down the middleware stack - such as
> Authentication-ID/Authorization-ID. So there's ususally an application
> specific requestcontext and not just a logger.
>
> /Peter
>

-- 
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: Generics and readability

['Axel Wagner' via golang-nuts]

Maybe a loaded question but what is the goal of this thread? Is it to
establish whether or not generics impact readability? In that case it
should get a lot more civil and charitable on both sides.

Anyway, my take on that: The examples mentioned, in a very real way, are
not really suitable to discuss that question. Any readability impact comes
not so much from simple declarations, but from a) how frequent
type-parameterized objects are going to be and b) how often we can omit the
type-parameteres. The issues are things like parameterized type-parameters
(today this example
 flew through
my twitter stream, to illustrate the point) and extra layers of abstraction
(like using a Map instead of a map[string]int).

Basically, we have three opposing forces: 1) How powerful the generics
implementation is, that is what are the things that can be parameterized,
2) How powerful type-inference is for them, that is in which specific
circumstances types can be omitted (this is the vital "readability" part)
and 3) How simple the description of them is, that is how easy is it to
understand failed type-checks to the programmer and how much space would
they take up in the spec and/or implementation.

Currently, Go *mostly* has 1 near zero (it is a little positive due to the
existence of map, [], chan… and append/copy/…), in preference of 2 and 3.
Most people agree, that 1 should get a little more love though. It's easy
to come up with syntax or semantics that make 1 large, but the issue is,
that while we want to increase 1, we don't just want to neglect 2 and 3.

Most languages with powerful generics will also include a lot of machinery
for 2, that is a complicated type-inference mechanism. Because it's so
complicated, they will mostly omit 3, that is they will not specify how
exactly it works and leave that up to the implementation, giving them the
flexibility to tune the intelligence over time. Most of them (*cough* C++

*cough*) also completely fail to provide meaningful error messages for even
reasonably simple failures.

Now, it's easy to just write down *some* generic (or not generic) code to
illustrate some level of readability. But to actually see the effects, a
lot more and realistic code is needed and we *need* to talk about 2 and 3.
An incredibly good example for how to discuss these is Ian's Proposal for
type parameters
.
It gives a detailed description of the power, the type-inference mechanism
and the complexity of implementation. AIUI, it failed because of 3.

Not every message or opinion about this, of course, needs this level of
detail. But just ignoring the complexity is oversimplifying and doesn't do
your position a lot of favor.
A better way to talk about readability would be, to take a real piece of
code that you'd like to write generically (or predict that people would
write), take one or two of the existing (declined) proposals and write your
code down assuming it where implemented. The advantage is, that the
proposals usually are detailed enough to meaningfully talk about the
tradeoffs involved and to be sure that "the compiler can infer that" isn't
just hand-waved.

But Hot-Takes don't really help anyone.

On Fri, Aug 25, 2017 at 10:11 AM, Egon  wrote:

> package tree
>
> type Node<$Entry> struct {
> Value $Entry
> Left  *Node<$Entry>
> Right *Node<$Entry>
> }
>
> func (node *Node) Insert(value node.$Entry) {
> var side **Node
> if node.Value.Less(value) {
> side = 
> } else {
> side = 
> }
>
> if *side == nil {
> *side = {Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
> --
>
> package tree
>
> type Entry generic {
> Less(Entry) bool
> }
>
> type Node struct {
> Value Entry
> Left  *Node
> Right *Node
> }
>
> func (node *Node) Insert(value Entry) {
> var side *Node
> if node.Value.Less(value) {
> side = 
> } else {
> side = 
> }
>
> if *side == nil {
> *side = {Value: value}
> } else {
> (*side).Insert(value)
> }
> }
>
>
> On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>>
>> Why would you put generics on a method ?
>>
>> The syntax you demonstrate is horrible, indeed.
>>
>> what if generics are type related
>>
>> type notFinal struct {
>>p1 
>>p2 
>> }
>>
>> func (n notFinal) whatever(in ) string {
>>return fmt.Sprintf(in) // anything to interface{}, works.
>> }
>>
>> type Final notFinal
>>
>> Final.whatever(1) // "1"
>>
>> //notFinal not instantiable, not type assertable
>>
>>
>>
>> Or func related
>>
>> type notFinal func(in ) string
>>
>> func Final notFinal
>>
>> Final(1) // "1"
>>
>>
>> That said, ultimately, the more the syntax is parametrized the more
>> complex it become. when there are many func signature as you demonstrate,
>> it will 

[go-nuts] Re: Generics and readability

[Egon]

package tree

type Node<$Entry> struct {
Value $Entry
Left  *Node<$Entry>
Right *Node<$Entry>
}

func (node *Node) Insert(value node.$Entry) {
var side **Node
if node.Value.Less(value) {
side = 
} else {
side = 
} 

if *side == nil {
*side = {Value: value}
} else {
(*side).Insert(value)
}
}

--

package tree

type Entry generic {
Less(Entry) bool
}

type Node struct {
Value Entry
Left  *Node
Right *Node
}

func (node *Node) Insert(value Entry) {
var side *Node
if node.Value.Less(value) {
side = 
} else {
side = 
} 

if *side == nil {
*side = {Value: value}
} else {
(*side).Insert(value)
}
}


On Thursday, 24 August 2017 20:08:16 UTC+3, mhh...@gmail.com wrote:
>
> Why would you put generics on a method ?
>
> The syntax you demonstrate is horrible, indeed.
>
> what if generics are type related
>
> type notFinal struct {
>p1 
>p2 
> }
>
> func (n notFinal) whatever(in ) string {
>return fmt.Sprintf(in) // anything to interface{}, works.
> }
>
> type Final notFinal
>
> Final.whatever(1) // "1"
>
> //notFinal not instantiable, not type assertable
>
>
>
> Or func related
>
> type notFinal func(in ) string
>
> func Final notFinal
>
> Final(1) // "1"
>
>
> That said, ultimately, the more the syntax is parametrized the more 
> complex it become. when there are many func signature as you demonstrate, 
> it will get worse.
>
> Named type might help, could be vetted too ?
>
> Also 
> none of this is as powerful as code gen.
> None of those examples are better than interface{}.
>
> On Thursday, August 24, 2017 at 5:14:58 PM UTC+2, JuciÊ Andrade wrote:
>>
>> A lot of people like Go because code is very readable even for beginners.
>>
>> func f(x, y int)
>>
>> f is a function that receives x and y as int parameters, returning 
>> nothing. Simple enough.
>>
>> func f(x, y int) int
>>
>> f is a function that receives x and y as int parameters, returning yet 
>> another int. Fine.
>>
>> func f(x, y int) (z int, err error)
>>
>> f is a function that receives x and y as int parameters, returning two 
>> values: a first int, that we name z and an error named err. A little bit 
>> weird, but ok.
>>
>> func (r MyType) f(x, y int) (z int, err error)
>>
>> f is a method for a value of type MyType, henceforth named r, that 
>> receives x and y as int parameters, returning two values: a first int, that 
>> we name z and an error named err. Definitely not so simple.
>>
>>  func (r genType1) f(x, y genType2) (z getType2, err 
>> error)
>>
>> You must be kidding. STOP RIGHT THERE!
>>
>>

-- 
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: Generics and readability

[Viktor Kojouharov]

func Foo(in interface{}) {
val, ok := in.(someTypeOrInterface)
if !ok {
 // TODO HANDLE ERROR
}
   ...
}


Wow, this is so much more readable /s


On Thursday, August 24, 2017 at 6:14:58 PM UTC+3, JuciÊ Andrade wrote:
>
> A lot of people like Go because code is very readable even for beginners.
>
> func f(x, y int)
>
> f is a function that receives x and y as int parameters, returning 
> nothing. Simple enough.
>
> func f(x, y int) int
>
> f is a function that receives x and y as int parameters, returning yet 
> another int. Fine.
>
> func f(x, y int) (z int, err error)
>
> f is a function that receives x and y as int parameters, returning two 
> values: a first int, that we name z and an error named err. A little bit 
> weird, but ok.
>
> func (r MyType) f(x, y int) (z int, err error)
>
> f is a method for a value of type MyType, henceforth named r, that 
> receives x and y as int parameters, returning two values: a first int, that 
> we name z and an error named err. Definitely not so simple.
>
>  func (r genType1) f(x, y genType2) (z getType2, err 
> error)
>
> You must be kidding. STOP RIGHT THERE!
>
>

-- 
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] Should we stop using a global logger?

[Peter Mogensen]

On 2017-08-25 08:31, Henrik Johansson wrote:
> How do you code for storing a logger in context.Value? The same usual
> issues with lacking a shared logger interface happens or did I miss
> something neat?
> 

I try not to do logging from libraries. So logging (and the logger
interface) is specific to my application.

Internally I would pass loggers as arguments, but using context.Context
becomes relevant when building a middleware stack. So the application
installs both the middleware creating the logger and the handler using
it. (and they then both know the type).
There can be other application specific request-scoped stuff you want to
pass along down the middleware stack - such as
Authentication-ID/Authorization-ID. So there's ususally an application
specific requestcontext and not just a logger.

/Peter

-- 
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: Should we stop using a global logger?

[Peter Mogensen]

On 2017-08-25 05:58, Dave Cheney wrote:
>> Should we stop using a global logger?
> 
> Yes[1]
> 
> 1. https://dave.cheney.net/2017/01/26/context-is-for-cancelation
>

fair point...

It can be very tempting though. Especially dealing with an HTTP
middleware stack where you need handlers to log and automatically add
Req-ID to the logging.
Unless of course, you use a middleware framework designed to make a
logger available.

/Peter

-- 
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: Should we stop using a global logger?

[Dave Cheney]

On Friday, 25 August 2017 16:02:48 UTC+10, snmed wrote:
>
> Hi Dave
>
> I've read about this context.Value topic on several occasion and in your 
> blog post you say context is only for cancelation. But how should one cope 
> with real goroutine specific data, unfortunately i missed always a correct 
> solution for this problem.
>

My recommendation is to pass it down from function to function, either as 
an argument, or as fields accessible from a method. 
 

> Any proposal is welcome
>
> Cheers snmed
>
>

-- 
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] Should we stop using a global logger?

[Henrik Johansson]

How do you code for storing a logger in context.Value? The same usual
issues with lacking a shared logger interface happens or did I miss
something neat?

On Fri, 25 Aug 2017, 08:26 Peter Mogensen  wrote:

>
>
> On 2017-08-25 05:38, buchanae.o...@gmail.com wrote:
> > - We create a child logger instance which has the ID preconfigured, and
> > pass that to some function calls. [3]
>
> I think several log packages has the feature build in.
>
> > instances everywhere. I think we can make either work, and so far
> > neither is an obvious choice. What do you think?
>
> IMHO ideally, you should use local logger instances. But that of course
> only becomes gradually more relevant the larger and more modularized the
> application becomes.
>
> > A third, interesting option might be to add all logging configuration to
> > the context using context.Value,
>
> I'd prefer this option in many cases. However, I probably wouldn't put
> formatting preferences into context.Value.
>
> A third way to use flexible logging is to have a global logger registry
> like the python "logging" package where each part of the code can
> acquire its logger with GetLogger(name). Loggers are then arranged in a
> hierarchy so you don't have to configure formatting for each individually.
>
> /Peter
>
> --
> 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] Should we stop using a global logger?

[Peter Mogensen]

On 2017-08-25 05:38, buchanae.o...@gmail.com wrote:
> - We create a child logger instance which has the ID preconfigured, and
> pass that to some function calls. [3]

I think several log packages has the feature build in.

> instances everywhere. I think we can make either work, and so far
> neither is an obvious choice. What do you think?

IMHO ideally, you should use local logger instances. But that of course
only becomes gradually more relevant the larger and more modularized the
application becomes.

> A third, interesting option might be to add all logging configuration to
> the context using context.Value,

I'd prefer this option in many cases. However, I probably wouldn't put
formatting preferences into context.Value.

A third way to use flexible logging is to have a global logger registry
like the python "logging" package where each part of the code can
acquire its logger with GetLogger(name). Loggers are then arranged in a
hierarchy so you don't have to configure formatting for each individually.

/Peter

-- 
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: Should we stop using a global logger?

[snmed]

Hi Dave

I've read about this context.Value topic on several occasion and in your blog 
post you say context is only for cancelation. But how should one cope with real 
goroutine specific data, unfortunately i missed always a correct solution for 
this problem.

Any proposal is welcome

Cheers snmed

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