[go-nuts] Re: Named or unnamed struct initialisation? What is best practice?

[snmed]

Hi rob

Thanks for your response. I didn't know that trick, but it seems to me a 
little bit ugly to guard fields that way. I will stick to named 
initialisations and write it as a policy into the style guide.

Cheers

Am Donnerstag, 6. Juli 2017 02:26:27 UTC+2 schrieb rob rodgers:
>
> for some of our sensitive structures that are tricky and have multiple 
> fields of the same type, there is a trick you can use:
>
> type bar struct {
>A int
>_ bool
> }
>
> see https://play.golang.org/p/rFKGoKq-S9
>
>
>

-- 
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] Template func ParseFiles, parsing multiple files

[Tong Sun]

What would it happen if I pass two or more files to:

func (*Template) ParseFiles 

❖ 

func (t *Template ) 
ParseFiles(filenames ...string ) (*Template 
, error 
)

ParseFiles parses the named files and associates the resulting templates 
with t. If an error occurs, parsing stops and the returned template is nil; 
otherwise it is t. There must be at least one file. Since the templates 
created by ParseFiles are named by the base names of the argument files, t 
should usually have the name of one of the (base) names of the files. If it 
does not, depending on t's contents before calling ParseFiles, t.Execute 
may fail. In that case use t.ExecuteTemplate to execute a valid template.

When parsing multiple files with the same name in different directories, 
the last one mentioned will be the one that results.

E.g., 

What would the differences be that affects the output, for 

MyTempl.ParseFiles(tf1)

vs. 

MyTempl.ParseFiles(tf1,tf2)? 

Will the content of tf2 be appended to tf1? 

Thx

-- 
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: [ANN] go-dedup/simhash, enhanced Go simhash package

[Damian Gryski]

On Tuesday, July 4, 2017 at 10:56:35 PM UTC+2, Tong Sun wrote:
>
> Good to know. 
>
> One question, I didn't find any help/text on how to use it -- why for so 
> many years, there is no usage help? My guess was that it is mainly for 
> internal use, not for the general public, but maybe I was wrong. 
>
>
>
A little bit of both.  It was initially developed on my own time out of 
pure interest.  Then a month or so later it turned out we needed it at 
work, so I did a bunch more work on it and then various performance 
improvements both as needed for work for my own interest.  For example, the 
compressed table support was initially for my own interest, but then as our 
data set grew we enabled it.

I agree there is virtually no documentation for it :(  I do know however 
that a few other people are actually running it.  I'm in the middle of an 
international move right now (Amsterdam -> Vancouver), but I'll try to find 
some time to write some documentation for it.

Damian


 

-- 
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: Named or unnamed struct initialisation? What is best practice?

[Dan Kortschak]

On Wed, 2017-07-05 at 17:26 -0700, rsr via golang-nuts wrote:
> type bar struct {
>    A int
>    _ bool
> }


or `type bar struct { A int; _ [0]byte }` to avoid the additional byte use.

-- 
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] Google API Go Client - Get Admin.User.ExternalID mapped to type UserExternalId struct

[chris . r . malek]

To anyone who has worked with  google.golang.org/api/admin/directory/v1



I am doing some automation with the Directory API.  I get a user from the 
Gsuite Directory and want to get the user.ExternalID mapped into a type 
userExternalId. It seems Admin.User.ExternalID is defined  as a interface{} 
(https://github.com/google/google-api-go-client/blob/master/admin/directory/v1/admin-gen.go#L2621)
 
 and maybe the JSON unmarshalling does not work as I am expecting it.  

I can't seem to figure out how to get easily get the 
*admin.User.ExternalIds that is returned from a user get operation into a 
an []admin.UserExternalId{} 
(https://github.com/google/google-api-go-client/blob/master/admin/directory/v1/admin-gen.go#L2879)


I am sure I am just missing something in the documents.

-- 
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] Interrupting stdout writer for runaway child process on Windows

[staticlimit]

I have a customer that launched reg.exe with the /f switch and created a 
monster (it looks like reg.exe prompts for user input, reads stdin, sees 
the EOF and re-writes the prompt to stdout in a tight loop).

I've tried several different ways to stop the write and ended up with a 
wrapper writer with an interrupt channel and several sleep statements to 
allow the goroutines to yield long enough to notice cancel.  I'm curious if 
the community knows a better way to force these goroutines to yield so I 
can stop the process without introducing sleeps?

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

The main process is PowerShell and it ends even though Reg continues to run 
- I'm not trying to solve that (It may not be ideal, but it is acceptable 
as long as we can prevent it from filling the disk with the stdout file).

This problem seems to be a combination of this: 
https://github.com/golang/go/issues/13155 (runaway child processes don't 
allow output to close, hanging command.wait) and the high frequency writes 
preventing the timeout signal from being recognized.

-- 
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: Named or unnamed struct initialisation? What is best practice?

[rsr via golang-nuts]

for some of our sensitive structures that are tricky and have multiple 
fields of the same type, there is a trick you can use:

type bar struct {
   A int
   _ bool
}

see https://play.golang.org/p/rFKGoKq-S9


-- 
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: The "call" function of Go template

[Tong Sun]

Thanks a lot!

On Wednesday, July 5, 2017 at 8:16:09 PM UTC-4, Guy Allard wrote:
>
> Maybe take a look at:
>
> https://github.com/golang/go/issues/10653
>
> and/or
>
> https://play.golang.org/p/Ka8bN3_V1f
>
> to understand what works, and what does not.
>
>
> On Wednesday, July 5, 2017 at 11:58:02 AM UTC-4, Tong Sun wrote:
>>
>> Can somebody give an example for the following? I made several attempts 
>> but none is working. Thanks. 
>>
>> call
>>  Returns the result of calling the first argument, which
>>  must be a function, with the remaining arguments as parameters.
>>  Thus "call .X.Y 1 2" is, in Go notation, dot.X.Y(1, 2) where
>>  Y is a func-valued field, map entry, or the like.
>>  The first argument must be the result of an evaluation
>>  that yields a value of function type (as distinct from
>>  a predefined function such as print). The function must
>>  return either one or two result values, the second of which
>>  is of type error. If the arguments don't match the function
>>  or the returned error value is non-nil, execution stops.
>>
>>
>>
>>

-- 
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: The "call" function of Go template

[Guy Allard]

Maybe take a look at:

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

and/or

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

to understand what works, and what does not.


On Wednesday, July 5, 2017 at 11:58:02 AM UTC-4, Tong Sun wrote:
>
> Can somebody give an example for the following? I made several attempts 
> but none is working. Thanks. 
>
> call
>   Returns the result of calling the first argument, which
>   must be a function, with the remaining arguments as parameters.
>   Thus "call .X.Y 1 2" is, in Go notation, dot.X.Y(1, 2) where
>   Y is a func-valued field, map entry, or the like.
>   The first argument must be the result of an evaluation
>   that yields a value of function type (as distinct from
>   a predefined function such as print). The function must
>   return either one or two result values, the second of which
>   is of type error. If the arguments don't match the function
>   or the returned error value is non-nil, execution stops.
>
>
>
>

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

Re: [go-nuts] Why the default format for nil slice and map is not nil?

[David Collier-Brown]

Hmmn: David J. Brown (my evil twin) was exceedingly good at unpainting 
himself from corners, did you know him? He as a Sun and SGI guy...
Methinks merging two formats into (one better) one were amoung the things 
we did...

-- 
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] Capture test output per-function

[buchanae . ohsu]

In Funnel, we have a growing end-to-end test suite which has many test 
functions.
https://github.com/ohsu-comp-bio/funnel/tree/master/tests/e2e

When one test fails, Funnel's logs are dumped, and there are lots of them. 
Debugging tests has become difficult. As far as I can tell, go test 
captures the output per-package, and when one test fails it dumps all the 
captured logs.

Possibly I'm approaching things the wrong way, so here I am asking the 
gurus (or gorus?) :) What can I do better? These are some ideas:

1) Find a way to capture output per-test without modifying Funnel logging 
code. Maybe I can do something with TestMain, subtests, I don't know.
2) Add better tracing info to the logs, so that each log entry has some 
context that can be grep'ed for. This would make our logs more useful in 
general, but will take some work.
3) Reconfigure the logger per-test, at the beginning of each test. Maybe 
write the logs to a file. Our tests are not currently run in parallel, but 
I'd like to leave that door open, and this might make that more difficult 
because the logger is global.
4) Don't dump the logs during tests, just get the failed list, and then run 
those tests individually.

Thanks in advance!
Alex

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

Re: [go-nuts] Why the default format for nil slice and map is not nil?

[Rob Pike]

It's probably just me not thinking things through in the early days of
building the Go libraries. There's a lot of that. Hindsight is easy;
foresight not so much.

-rob


On Wed, Jul 5, 2017 at 11:46 PM, Yann Salaün  wrote:

> Hello,
>
> I was surprised to realize today that the default format for a nil slice
> or map is the same as the default format for an empty one. However, this is
> not the case for a nil chan or func.
>
> See this playground link for an example: https://play.golang.
> org/p/OtoFRxjD61
>
> I would be very interested to understand why it was decided that the
> default format for the nil slice and map would not be nil.
>
> Thank you,
>
> --
> 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] Uncontrolled map access can crash the program --- how?

['Thomas Bushnell, BSG' via golang-nuts]

On Wed, Jul 5, 2017 at 12:29 PM Peter Kleiweg  wrote:

> From the faq: https://golang.org/doc/faq#atomic_maps
>
>  ... uncontrolled map access can crash the program.
>
> In what situations does this apply?
>
> Can I have two goroutines reading a single map at the same time?
>

Yes.


> Can I have one goroutine putting something in a map while at the same time
> another goroutine is reading the map?
>

This has a risk of crashes or arbitrary data corruption.


> Does it depend on the type of the key or the type of the value?
>

No.

Thomas

-- 
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] Uncontrolled map access can crash the program --- how?

[Peter Kleiweg]

>From the faq: https://golang.org/doc/faq#atomic_maps

 ... uncontrolled map access can crash the program.

In what situations does this apply?

Can I have two goroutines reading a single map at the same time?
Can I have one goroutine putting something in a map while at the same time 
another goroutine is reading the map?
Does it depend on the type of the key or the type of the value?

-- 
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] make.bash must be run from $GOROOT/src

[Dave Cheney]

The error message you received is correct; try something like this. 

(cd /usr/local/go/src && ./make.bash)

-- 
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: foo.Bar syntax clash - why?

[ojucie]

Everton, I think that is for the sake of simplicity.

Let's consider C++ for a moment. In C++ you have a different operator for 
each of these situations:
foo.Bar access to member Bar from object foo
foo->Bar access to member Bar thru object pointer foo
foo::Bar access to member Bar from the namespace foo

That is three operators to explain, three operators to write documentation 
about, three operators to choose from when programming.

In each of these situations, if by any chance the programmer uses the wrong 
operator, C++ compiler emits an error. Why? Because it allways knows what 
is needed in each situation. Try it. Try using an arrow where a dot is 
expected. The compiler will complain.

Go takes the opposite approach. If the compiler allways knows what is 
needed, why should it bother the programmer? Let's use only dot. End of 
story.


On Wednesday, July 5, 2017 at 11:43:43 AM UTC-3, Everton Marques wrote:
>
> If context is not given, I can't tell if foo.Bar() is a function of 
> package foo or a method of variable foo.
> That is, dot is used both for package namespace and method call.
>
> Example:
>
> type T struct {
> }
>
> func (t T) Println(s string) {
> fmt.Println("method: " + s)
> }
>
> func main() {
> fmt.Println("hello from package function")
> fmt := T{}
> fmt.Println("hello")
> }
>
> https://play.golang.org/p/HZibMmJ8W5
>
> I wonder if such an ambiguity came into Go...
> 1) on purpose, since the dot (.) is easy on the eye and simple key stroke 
> (shift not needed) ?
> 2) by accident, since keyboards lack convenient alternate symbols ?
> 3) for other reasons ?
>
> Everton
>
>

-- 
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] How to access pointer to pointer in cgo

[Manohar Reddy]

okay the golang’s alternative for `optional->_32->Magic` is simply 
`optional._32.Magic.`


So I’ve written my code regarding the about statement is given in 
https://play.golang.org/p/8sIAlxsmcj


Thanks, solved.


On Wednesday, July 5, 2017 at 7:02:10 PM UTC+5:30, Nathan Kerr wrote:
>
> Did you assign something to the pointer?
>
> My guess is that you did not, because the code compiles and then fails at 
> runtime telling the pointer is NULL.
>
> On Wednesday, July 5, 2017 at 1:19:47 PM UTC+2, Manohar Reddy wrote:
>>
>> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
>> MAGIC VARIABLE
>>
>> This line returns null pointer de-reference at run time. 
>> Can you please guide me on how what is the  alternative for optional->_32
>> ->Magic in Golang?
>>
>> Thanks
>> On Wednesday, July 5, 2017 at 4:42:07 PM UTC+5:30, Jan Mercl wrote:
>>>
>>> On Wed, Jul 5, 2017 at 1:04 PM Manohar Reddy  wrote:
>>>
>>> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
>>> MAGIC VARIABLE
>>>
>>> Who wants to guess what does "did not work for me" mean without having 
>>> the source code and the compiler output to look at?
>>>
>>> Please post a complete example at eg. the Go playgound: 
>>> https://play.golang.org/
>>>
>>> -- 
>>>
>>> -j
>>>
>>

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

[go-nuts] Re: Switching from rsc.io/letsencrypt to x/crypto/acme/autocert

[Diego Medina]

yes, you provide the storage implementation and the library will use it 
when it needs to store/retrieve certs



On Wednesday, July 5, 2017 at 10:48:26 AM UTC-4, Daniel Martí wrote:
>
> Hi all, 
>
> One project I contribute to started using rsc.io/letsencrypt years ago. 
> Now that it's recommended to switch to the latter, I've been looking 
> into getting it done. 
>
> But I'm confused as to what happened to Manager.Marshal and 
> Manager.Unmarshal. We use these to store the state somewhere and get it 
> back at a later time. 
>
> Were these removed on purpose from acme/autocert? What's the recommended 
> alternative? 
>
> I've seen Manager.Cache but it seems different. Instead of getting or 
> setting the state at will, you instead supply the storage 
> implementation. Is this what we should be using? 
>
> Thanks! 
>
> -- 
> Daniel Martí - https://mvdan.cc/ 
>

-- 
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] Maximum number of requests per HTTP connection?

[Kevin Malachowski]

Creating an http.RoundTripper which was in charge of delegating to an 
http.Transport as well as swapping out to a new http.Transport when you want to 
swap underlying connections is probably what I'd try first.

Cleaning up the old transport might be a little tricky if your application ever 
leaks http.Response.Body by not closing it appropriately, at which point you 
could also swap out the http.Transport.Dial functions with something which keep 
track of the underlying network connections. That would allow you to 
force-close them after some time out.

-- 
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] The "call" function of Go template

[Tong Sun]

Can somebody give an example for the following? I made several attempts but 
none is working. Thanks. 

call
Returns the result of calling the first argument, which
must be a function, with the remaining arguments as parameters.
Thus "call .X.Y 1 2" is, in Go notation, dot.X.Y(1, 2) where
Y is a func-valued field, map entry, or the like.
The first argument must be the result of an evaluation
that yields a value of function type (as distinct from
a predefined function such as print). The function must
return either one or two result values, the second of which
is of type error. If the arguments don't match the function
or the returned error value is non-nil, execution stops.



-- 
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] gccgo on Solaris (I got it to work)

[Stephen Bancroft]

I know there may not be much demand for this these days, but I find myself 
in a job working with Solaris daily and I needed to have access to go. 

After many hours of searching the internet and many failed attempts I was 
finally able to compile gccgo for Solaris 11.3 (11.3.13.4). I'm posting 
this here because most things you find on this topic will be discussing 
Solaris 10 or older versions of Solaris, I had to tweek and modify to get 
things working, so I hope this helps someone else.

1) Start by installing necessary packages from rep

  # pkg install gmp
 # pkg install mpc
 # pkg install mpfr here...

2) Setup some directories

 mkdir -p $HOME/src/gccgo
 cd $HOME/src/gccgo


3) Get the gccgo source (I've used version 6 of golang here)

 svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
gccgo-src


4) create a new script (this is where the magic happens) I cannot take all 
the credit for this. This whole thing was inspired by THIS 
 
post from this group, but once again it was a few years old and needed 
updating. vi build-gcc.sh

#!/bin/sh

dir=$HOME/src/gccgo
srcdir=$dir/gccgo-src
objdir=$dir/gccgo-obj
prefix=$dir/gccgo

jobs=8

export PATH=/usr/gcc/4.8/bin:/usr/sfw/bin:/usr/gnu/bin:/usr/bin
export LD_OPTIONS='-R$ORIGIN/../lib/ -R/usr/gnu/lib -R/usr/sfw/lib'

languages="--enable-languages=go,"
version="--with-pkgversion=gccgo-249045"
options="--with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/bin/ld 
--without-gnu-ld --with-gmp-include=/usr/include/gmp 
--with-gmp-lib=/usr/lib --with-mpfr-include=/usr/include/mpfr 
--with-mpfr-lib=/usr/lib --with-mpfr=/usr/include --with-mpc=/usr/include 
--disable-nls --disable-libquadmath --disable-libssp --disable-lto 
--disable-libgomp --with-build-time-tools=/usr/sfw"

multilib="--enable-multilib"
shared="--enable-shared"
static="--enable-static"

if [ ! -d $objdir ]; then
 mkdir $objdir
fi

cd $objdir
$srcdir/configure --prefix=$prefix "$languages" $options $shared $static 
$multilib "$version" && gmake -j$jobs

4) set perms and run script

 chmod +x build-gcc.sh
./build-gcc.sh


5) Sit back and watch the fun!

Once the compile has finished you will have a statically linked binary that 
you can put where ever you like. WINNING!

bancroft@box:~/src/gccgo/gccgo-obj/gcc$ uname -a
SunOS box 5.11 11.3 sun4v sparc SUNW,Sun-Fire-T200 Solaris
bancroft@box:~/src/gccgo/gccgo-obj/gcc$ ./gccgo --version
gccgo (gccgo-249045) 6.3.1 20170703
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Let me know how you get on..

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

[go-nuts] Why the default format for nil slice and map is not nil?

[Yann Salaün]

Hello,

I was surprised to realize today that the default format for a nil slice or
map is the same as the default format for an empty one. However, this is
not the case for a nil chan or func.

See this playground link for an example:
https://play.golang.org/p/OtoFRxjD61

I would be very interested to understand why it was decided that the
default format for the nil slice and map would not be nil.

Thank you,

-- 
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] make.bash must be run from $GOROOT/src

[Kallen Ding]

I want install golang on freebsd8.4 via source tarball, I execute `
*./all.bash*` after I extract the tar and into go/src, It occurs this:

```
 /usr/local/go/src/all.bash 

make.bash must be run from $GOROOT/src
```
My go env is:
```
[root@freebsd /usr/local/go/src]# go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="freebsd"
GOOS="freebsd"
GOPATH="/usr/local/golang"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/freebsd_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0"
CXX="clang++"
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"
```
And the go version is: `go1.8.3 freebsd/amd64`.
My os is: `FreeBSD 8.4-RELEASE`.


-- 
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] Switching from rsc.io/letsencrypt to x/crypto/acme/autocert

[Daniel Martí]

Hi all,

One project I contribute to started using rsc.io/letsencrypt years ago.
Now that it's recommended to switch to the latter, I've been looking
into getting it done.

But I'm confused as to what happened to Manager.Marshal and
Manager.Unmarshal. We use these to store the state somewhere and get it
back at a later time.

Were these removed on purpose from acme/autocert? What's the recommended
alternative?

I've seen Manager.Cache but it seems different. Instead of getting or
setting the state at will, you instead supply the storage
implementation. Is this what we should be using?

Thanks!

-- 
Daniel Martí - https://mvdan.cc/

-- 
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] foo.Bar syntax clash - why?

[Everton Marques]

If context is not given, I can't tell if foo.Bar() is a function of package 
foo or a method of variable foo.
That is, dot is used both for package namespace and method call.

Example:

type T struct {
}

func (t T) Println(s string) {
fmt.Println("method: " + s)
}

func main() {
fmt.Println("hello from package function")
fmt := T{}
fmt.Println("hello")
}

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

I wonder if such an ambiguity came into Go...
1) on purpose, since the dot (.) is easy on the eye and simple key stroke 
(shift not needed) ?
2) by accident, since keyboards lack convenient alternate symbols ?
3) for other reasons ?

Everton

-- 
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] http2.Transport connections seem to occasionally get "stuck"

[Andy Balholm]

Users of github.com/andybalholm/redwood (an HTTP proxy) are running into an 
intermittent problem that I suspect is an HTTP/2 bug. But it is very difficult 
to pin down.

The symptom reported by the customers is that, for an hour or two, all 
connections to Google servers through the proxy time out. If the proxy is 
restarted, they work fine. My suspicion is that the proxy is multiplexing all 
the connections to Google servers on a single HTTP/2 connection, and somehow 
that connection is getting into an unusable state but not closing or returning 
an error.

The user that has this problem most frequently is using a 4G cellular 
connection, so network flakiness could definitely be a factor in triggering 
this situation.

Andy

-- 
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] How to access pointer to pointer in cgo

[Nathan Kerr]

Did you assign something to the pointer?

My guess is that you did not, because the code compiles and then fails at 
runtime telling the pointer is NULL.

On Wednesday, July 5, 2017 at 1:19:47 PM UTC+2, Manohar Reddy wrote:
>
> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
> MAGIC VARIABLE
>
> This line returns null pointer de-reference at run time. 
> Can you please guide me on how what is the  alternative for optional->_32
> ->Magic in Golang?
>
> Thanks
> On Wednesday, July 5, 2017 at 4:42:07 PM UTC+5:30, Jan Mercl wrote:
>>
>> On Wed, Jul 5, 2017 at 1:04 PM Manohar Reddy  wrote:
>>
>> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
>> MAGIC VARIABLE
>>
>> Who wants to guess what does "did not work for me" mean without having 
>> the source code and the compiler output to look at?
>>
>> Please post a complete example at eg. the Go playgound: 
>> https://play.golang.org/
>>
>> -- 
>>
>> -j
>>
>

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

[go-nuts] Re: Do we need to close response.Body before closing it?

[James Bardin]

On Wednesday, July 5, 2017 at 6:50:10 AM UTC-4, Yulrizka wrote:
>
>
> So in conclusion my question is do we need to always read the resp.Body 
> before closing it?
>
>
Yes, you need to read the body to reuse the connection, otherwise there may 
be still be data waiting to be read. 

You dug pretty deep here, but seemed to have skipped the documentation 
itself:

// The default HTTP client's Transport does not
// attempt to reuse HTTP/1.0 or HTTP/1.1 TCP connections
// ("keep-alive") unless the Body is read to completion and is
// closed.


-- 
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: Who wants to use Go to process your camera's raw files?

[Jonathan Pittman]

Unfortunately not from my end.  I have had a lot going on at work and
home.  Time to work on this has escaped me.

I did manage to move my initial prototyping work over to
github.com/google/tiff and update the LICENSE to match the Go license.  So,
this is where we can make changes or blow it all away and start fresh.

I will be at GopherCon this year (and GothamGo) if anyone wants to meet up
and discuss or start hacking on this.

On Tue, Jul 4, 2017 at 11:09 AM,  wrote:

> Any updates on this?
>
> I'm looking at processing RAW images in a server with Go.
>
>
> On Tuesday, July 26, 2016 at 9:36:31 PM UTC-5, Jonathan Pittman wrote:
>>
>> Well me too!  I am looking to see what level of interest there is in the
>> Go community to see this happen.  I am also looking for people who are
>> interested in working on this.
>>
>> Figuring out how to handle this problem for one specific camera's raw
>> files is not too difficult.  Figuring out how to do this to handle the
>> majority of cases requires a bit more work.
>>
>> To be clear, I am wanting a pure Go solution that is better thought out,
>> better laid out, and better to use than the existing C/C++ options.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/golang-nuts/60WthPS_TXg/unsubscribe.
> To unsubscribe from this group and all its topics, 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] How to access pointer to pointer in cgo

[Manohar Reddy]

> fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
MAGIC VARIABLE

This line returns null pointer de-reference at run time. 
Can you please guide me on how what is the  alternative for optional->_32->
Magic in Golang?

Thanks
On Wednesday, July 5, 2017 at 4:42:07 PM UTC+5:30, Jan Mercl wrote:
>
> On Wed, Jul 5, 2017 at 1:04 PM Manohar Reddy  > wrote:
>
> > fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS 
> MAGIC VARIABLE
>
> Who wants to guess what does "did not work for me" mean without having the 
> source code and the compiler output to look at?
>
> Please post a complete example at eg. the Go playgound: 
> https://play.golang.org/
>
> -- 
>
> -j
>

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

Re: [go-nuts] How to access pointer to pointer in cgo

[Jan Mercl]

On Wed, Jul 5, 2017 at 1:04 PM Manohar Reddy  wrote:

> fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS
MAGIC VARIABLE

Who wants to guess what does "did not work for me" mean without having the
source code and the compiler output to look at?

Please post a complete example at eg. the Go playgound:
https://play.golang.org/

-- 

-j

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

[go-nuts] How to access pointer to pointer in cgo

[Manohar Reddy]

These are the things I have in C.


IMAGE_OPTIONAL_HEADER *pe_optional(pe_ctx_t *ctx);

typedef struct {
  uint16_t Magic;
}IMAGE_OPTIONAL_HEADER_32;

typedef struct {
  uint16_t type;
  IMAGE_OPTIONAL_HEADER_32 *_32;
}IMAGE_OPTIONAL_HEADER;




In c language to access Magic variable, I did  this and it worked. 


IMAGE_OPTIONAL_HEADER *optional = pe_optional();
printf(“%d \n”, optional->_32->Magic)


But how to access the same in golnag? I did


optional := pe_optional();
fmt.Println(optional._type) // worked for me 
fmt.Println(optional._32.Magic) // did not work for me: HOW TO ACCESS MAGIC 
VARIABLE



Doubt is : how to do I access `Magic` variable in go?


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] Do we need to close response.Body before closing it?

[Yulrizka]

Hi

I was reading this thread 

https://stackoverflow.com/questions/17948827/reusing-http-connections-in-golang

and found this comment

one interesting note is that the read step appears to be necessary and 
> sufficient. 
> The read-step alone will return the connection to the pool, but the close 
> alone will not; the connection would end up in TCP_WAIT. 
> Also ran into trouble because I was using a json.NewDecoder() to read the 
> response.Body, which did not fully read it. 
> Make sure to include the io.Copy(ioutil.Discard, res.Body) if you're not 
> sure
>

Do we always need to do `io.Copy(ioutil.Discard, res.Body)` before closing 
the body?

I'm using go 1.8.3 and here is what i found so far:

>From the source code https://golang.org/src/net/http/response.go#L189

Body is assigend by `readTransfer` and is of type `http.body` 

https://golang.org/src/net/http/transfer.go#L724

http.body,  has comments

// body turns a Reader into a ReadCloser.
// Close ensures that the body has been fully read
// and then reads the trailer if necessary.
type body struct {
...
}

and the close method

func (b *body) Close() error {
b.mu.Lock()
defer b.mu.Unlock()
if b.closed {
return nil
}
var err error
switch {
case b.sawEOF:
// Already saw EOF, so no need going to look for it.
case b.hdr == nil && b.closing:
// no trailer and closing the connection next.
// no point in reading to EOF.
case b.doEarlyClose:
// Read up to maxPostHandlerReadBytes bytes of the body, looking for
// for EOF (and trailers), so we can re-use this connection.
if lr, ok := b.src.(*io.LimitedReader); ok && lr.N > 
maxPostHandlerReadBytes {
// There was a declared Content-Length, and we have more bytes 
remaining
// than our maxPostHandlerReadBytes tolerance. So, give up.
b.earlyClose = true
} else {
var n int64
// Consume the body, or, which will also lead to us reading
// the trailer headers after the body, if present.
n, err = io.CopyN(ioutil.Discard, bodyLocked{b}, 
maxPostHandlerReadBytes)
if err == io.EOF {
err = nil
}
if n == maxPostHandlerReadBytes {
b.earlyClose = true
}
}
default:
// Fully consume the body, which will also lead to us reading
// the trailer headers after the body, if present.
_, err = io.Copy(ioutil.Discard, bodyLocked{b})
}
b.closed = true
return err
}

It seems to me that it's already doing that. And if I understand correctly, 
the `b.doEarlyClose` only apply when reading request and not applicable to 
http response.

So in conclusion my question is do we need to always read the resp.Body 
before closing it?

Thank you.



-- 
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] question about func type

['Axel Wagner' via golang-nuts]

Orthogonality means (roughly) "independent" in this context.

I do agree with you, though, that the slide is incorrect. The spec
 defines type literals in the TypeLit
production (search in page), which clearly only refers to composite types.
The slides shouldn't talk about type literals, but only about "type", which
is, how it's refered to in the spec under "Type declarations
"


On Wed, Jul 5, 2017 at 11:39 AM, Darren Hoo  wrote:

>
>
> On Wed, Jul 5, 2017 at 5:27 PM, Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:
>>
>> >>> what is the relation between `type literal` and `named type`,
>> >>
>> >> Orthogonality.
>> >
>> > Then `int` is not named type.
>>
>> Please explain why do you think so. I don't get it.
>>
>
> In  https://talks.golang.org/2015/tricks.slide#5 says  int is type
> literal, then you say int is named type.
>
> How can int be both type literal and  named type while they are orthogonal?
>
> Can you explain orthogonality for me? Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 11:39 AM Darren Hoo  wrote:

> In https://talks.golang.org/2015/tricks.slide#5 says int is type literal,
then you say int is named type.
>
> How can int be both type literal and named type while they are orthogonal?

A type literal can be a named type or an anonymous type. IOW, being
named/anonymous plays no role in using the type in a type literal. Hence
the orhogonality (not dichotomy).

-- 

-j

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

Re: [go-nuts] question about func type

[Darren Hoo]

On Wed, Jul 5, 2017 at 5:27 PM, Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:
>
> >>> what is the relation between `type literal` and `named type`,
> >>
> >> Orthogonality.
> >
> > Then `int` is not named type.
>
> Please explain why do you think so. I don't get it.
>

In  https://talks.golang.org/2015/tricks.slide#5 says  int is type literal,
then you say int is named type.

How can int be both type literal and  named type while they are orthogonal?

Can you explain orthogonality for me? Thanks!

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:

>>> what is the relation between `type literal` and `named type`,
>>
>> Orthogonality.
>
> Then `int` is not named type.

Please explain why do you think so. I don't get it.

> `int` and `int64` are not the same in this regard?

Both are named types, nothing special about them except being predeclared
in the universe scope.

-- 

-j

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

Re: [go-nuts] question about func type

[Darren Hoo]

On Wed, Jul 5, 2017 at 5:06 PM, Jan Mercl <0xj...@gmail.com> wrote:

> On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:
>
> > what is the relation between `type literal` and `named type`,
>
> Orthogonality.
>

Then  `int` is not named type.

`int` and `int64` are not the same in this regard?

-- 
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] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 11:03 AM Darren Hoo  wrote:

> what is the relation between `type literal` and `named type`,

Orthogonality.

> aren't they mutually exclusive?

No. Otherwise `type T U` would be illegal.

-- 

-j

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

Re: [go-nuts] question about func type

[Darren Hoo]

On Wednesday, July 5, 2017 at 4:40:57 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Jul 5, 2017 at 10:33 AM Darren Hoo  > wrote:
>
> > So in https://talks.golang.org/2015/tricks.slide#5
> > 
> > Other examples of type literals are int and []string, 
> > 
> > is actually not correct. 
>
> The text is completely correct. Type literal is like a type expression. To 
> express/describe a type you can use any type, anonymous or named.
>

'u' and 'int64' are both named types.


`int` is type literal
`int64` is named type
 
IIUC,  `func (int)` is type literal but not named type

 what is the relation between  `type literal`  and `named type`, aren't 
they mutually exclusive?
  

-- 
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] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 10:33 AM Darren Hoo  wrote:

> So in https://talks.golang.org/2015/tricks.slide#5
>
> Other examples of type literals are int and []string,
>
> is actually not correct.

The text is completely correct. Type literal is like a type expression. To
express/describe a type you can use any type, anonymous or named.

-- 

-j

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

Re: [go-nuts] question about func type

[Darren Hoo]

Thanks all. I got it.

So in https://talks.golang.org/2015/tricks.slide#5
 

>   Other examples of type literals are int and []string, 


is actually not correct. 


On Wednesday, July 5, 2017 at 3:59:57 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Jul 5, 2017 at 9:54 AM Darren Hoo  > wrote:
>
> > which part did I misunderstand?
>
> 'u' and 'int64' are both named types.
>
>
>
> -- 
>
> -j
>

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 9:54 AM Darren Hoo  wrote:

> which part did I misunderstand?

'u' and 'int64' are both named types.



-- 

-j

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

Re: [go-nuts] question about func type

['Axel Wagner' via golang-nuts]

Yes, V is a named type. The name of V is uint64, which is a predeclared
identifier.

On Wed, Jul 5, 2017 at 9:54 AM, Darren Hoo  wrote:

> Thank you all!
>
> But I still don't quite understand why the rule does not apply to the
> first case?
>
> var a2 u = a1
>
> x ---> a1
> T ---> u
> V ---> uint64
>
> V and T has the identical underlying types (ie, uint64) and V is not a
> named type (literal) .
>
> which part did I misunderstand?
>
>
> On Wednesday, July 5, 2017 at 3:26:13 PM UTC+8, Jan Mercl wrote:
>>
>> On Wed, Jul 5, 2017 at 9:17 AM Darren Hoo  wrote:
>>
>> > f1's type is func(int), and f2's type is main.f, they are different
>> types, does implicit conversion happen here?
>>
>> It's not a conversion. The rule is about assignability
>> : "x's type V and T have
>> identical underlying types  and at
>> least one of V or T is not a named type
>> ."
>>
>> --
>>
>> -j
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] question about func type

[Darren Hoo]

Thank you all!

But I still don't quite understand why the rule does not apply to the first 
case?

var a2 u = a1 

x ---> a1
T ---> u
V ---> uint64

V and T has the identical underlying types (ie, uint64) and V is not a 
named type (literal) .

which part did I misunderstand?


On Wednesday, July 5, 2017 at 3:26:13 PM UTC+8, Jan Mercl wrote:
>
> On Wed, Jul 5, 2017 at 9:17 AM Darren Hoo  > wrote:
>
> > f1's type is func(int), and f2's type is main.f, they are different 
> types, does implicit conversion happen here? 
>
> It's not a conversion. The rule is about assignability 
> : "x's type V and T have 
> identical underlying types  and at 
> least one of V or T is not a named type 
> ."
>
> -- 
>
> -j
>

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

Re: [go-nuts] question about func type

[Jan Mercl]

On Wed, Jul 5, 2017 at 9:17 AM Darren Hoo  wrote:

> f1's type is func(int), and f2's type is main.f, they are different
types, does implicit conversion happen here?

It's not a conversion. The rule is about assignability
: "x's type V and T have
identical underlying types  and at least
one of V or T is not a named type ."

-- 

-j

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

[go-nuts] question about func type

[Dave Cheney]

Func types are just regular types so the rules of assignability apply equally 
to them as any other type. 

x's type V and T have identical underlying types and at least one of V or T is 
not a named type.

https://golang.org/ref/spec#Assignability

-- 
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] question about func type

[Darren Hoo]

package main

type u uint64
type f func(int)

func g(x int) {
}

func main() {
var a1 uint64 = 1000
var a2 u = a1 //why this is not OK

var f1 func(int) = g
var f2 f = f1 //while this is allowed? 
f2(1)
}

f1's type is func(int), and f2's type is main.f, they are different types, 
does implicit conversion happen here?

-- 
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: Named or unnamed struct initialisation? What is best practice?

[snmed]

Okay thanks, as I supposed. Personally i used always named initialisation 
despite of the overhead, but sometimes I feel the urge to use the short 
unamed initialisation. ;-)

Am Mittwoch, 5. Juli 2017 07:41:04 UTC+2 schrieb Tamás Gulácsi:
>
> Named.

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