Re: [go-nuts] How to determine the correct method signature to override fopen

[Ian Lance Taylor]

On Fri, Nov 3, 2017 at 5:44 PM,   wrote:
>
> Thanks Ian. I had included that because it seems required in order for me to
> refer to the return type (C.FILE) and so I can access the underlying C.fopen
> function.  This is the approach I have with open but perhaps this is
> different.
> If I'm not supposed to use the include, can you advise how I should refer to
> the type/function from the header?

I'm sorry, nothing comes to mind.  In C you would just write the
declaration the way the header file expects, but cgo doesn't provide a
way to do that.

Ian


> On Friday, November 3, 2017 at 8:28:38 PM UTC-4, Ian Lance Taylor wrote:
>>
>> On Fri, Nov 3, 2017 at 2:24 PM,   wrote:
>> >
>> > I've been writing a shared-object which I'll use via LD_PRELOAD to
>> > override
>> > the open syscall. This is currently working OK but now I want to move on
>> > to
>> > fopen. I've defined it (as far as I can tell) in-line with the stdio
>> > header
>> > see here. However, when I try and build:
>> >
>> > $ go build -buildmode=c-shared
>> > # github.com/walkert/loader
>> > In file included from
>> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0:
>> > ./main.go:56:14: error: conflicting types for ‘fopen’
>> > In file included from ./main.go:5:0,
>> >  from
>> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
>> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was
>> > here
>> >  extern FILE *fopen (const char *__restrict __filename,
>> >   ^
>> >
>> > /tmp/go-build775342366/github.com/walkert/loader/_obj/_cgo_export.c:17:7:
>> > error: conflicting types for ‘fopen’
>> >  FILE* fopen(char* p0, char* p1)
>> >^
>> > In file included from ./main.go:5:0,
>> >  from
>> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
>> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was
>> > here
>> >  extern FILE *fopen (const char *__restrict __filename,
>> >   ^
>> >
>> > I've seen this before when I was trying to return an int instead of
>> > C.int so
>> > I have a feeling I'm missing something simple here. Any pointers would
>> > be
>> > much appreciated.
>>
>> It looks like the same file is doing #include  and `//export
>> fopen`.  That won't work, because, as you can see, the definition of
>> the Go function fopen will conflict with the declaration in stdio.h.
>>
>> Ian
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [go-nuts] Re: appengine golang logs

[Sankar P]

I knew about this package. I mentioned about this in my mail itself :-)

I wanted a different way as it is not always possible to replace "log"
calls in all the existing code. Some libraries need to be used in binaries
which will be deployed outside appengine. They should not have a dependency
on appengine libraries ideally.


2017-11-03 23:01 GMT+05:30 Jim Cote :

> In appengine you have to use google.golang.org/appengine/log package.
> The log calls must have a context passed to it.
>
> See https://cloud.google.com/appengine/docs/standard/go/logs/reference.
>
>
> On Friday, November 3, 2017 at 3:58:34 AM UTC-4, Sankar wrote:
>>
>> Hi
>>
>>
>> I have a golang file where I have code like:
>>
>>
>> log.Fatal("My error message: ", err)
>>
>>
>> When the above statement is executed, In the appengine logviewer, I get
>> something like:
>>
>> panic: os.Exit called goroutine 1 [running]:
>> os.Exit(0x1)
>> go/src/os/proc.go:58
>> 
>> +0x7c log.Fatal(0xc008549f60, 0x2, 0x2)
>> go/src/log/log.go:303
>> 
>> +0x79 main.main()
>> main.go:42
>> 
>> +0x201
>>
>> But I dont get any error message. The main.go:42 corresponds to the
>> log.Fatal line in my code but I do not get to see the error message that is
>> printed as part of the log statement.
>>
>> I see that appengine package has a "Log" function which may print the
>> AppLogs such that they can be viewed from the Google Appengine log console
>> itself.
>>
>> My question is, can the golang default log package be somehow instructed
>> to redirect to appengine ? Something like:
>>
>> if env == "AppEngine" {
>>   log.SetOutput(appengine.DefaultLogger)
>> }
>>
>> in my main file ? This way, I get to make my code not locked to google
>> cloud and also can deploy existing code which uses log already.
>>
>> Any pointers ?
>>
>> Thanks.
>>
> --
> 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/XbhcR5eFdno/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.
>



-- 
Sankar P
http://psankar.blogspot.com

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

Re: [go-nuts] How to determine the correct method signature to override fopen

[tonywalker . uk]

This is without the include:

$ go build -buildmode=c-shared

# github.com/walkert

./main.go:6:41: could not determine kind of name for C.FILE

./main.go:7:8: could not determine kind of name for C.fopen

-- 
You received this message because you are subscribed 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 determine the correct method signature to override fopen

[tonywalker . uk]

Thanks Ian. I had included that because it seems required in order for me 
to refer to the return type (C.FILE) and so I can access the underlying 
C.fopen function.  This is the approach I have with open but perhaps this 
is different.
If I'm not supposed to use the include, can you advise how I should refer 
to the type/function from the header?

Tony

On Friday, November 3, 2017 at 8:28:38 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Nov 3, 2017 at 2:24 PM,   
> wrote: 
> > 
> > I've been writing a shared-object which I'll use via LD_PRELOAD to 
> override 
> > the open syscall. This is currently working OK but now I want to move on 
> to 
> > fopen. I've defined it (as far as I can tell) in-line with the stdio 
> header 
> > see here. However, when I try and build: 
> > 
> > $ go build -buildmode=c-shared 
> > # github.com/walkert/loader 
> > In file included from 
> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0: 
> > ./main.go:56:14: error: conflicting types for ‘fopen’ 
> > In file included from ./main.go:5:0, 
> >  from $WORK/
> github.com/walkert/loader/_obj/_cgo_export.c:3: 
> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was 
> here 
> >  extern FILE *fopen (const char *__restrict __filename, 
> >   ^ 
> > /tmp/go-build775342366/github.com/walkert/loader/_obj/_cgo_export.c:17:7: 
>
> > error: conflicting types for ‘fopen’ 
> >  FILE* fopen(char* p0, char* p1) 
> >^ 
> > In file included from ./main.go:5:0, 
> >  from $WORK/
> github.com/walkert/loader/_obj/_cgo_export.c:3: 
> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was 
> here 
> >  extern FILE *fopen (const char *__restrict __filename, 
> >   ^ 
> > 
> > I've seen this before when I was trying to return an int instead of 
> C.int so 
> > I have a feeling I'm missing something simple here. Any pointers would 
> be 
> > much appreciated. 
>
> It looks like the same file is doing #include  and `//export 
> fopen`.  That won't work, because, as you can see, the definition of 
> the Go function fopen will conflict with the declaration in stdio.h. 
>
> 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] Expected ambigiuous reference error, got a value instead

[Jan Mercl]

On Fri, Nov 3, 2017 at 11:04 PM Daniel Skinner  wrote:

> https://play.golang.org/p/Y1UxMgNhWx
>
> I ran into this today but don't understand why the compiler isn't
throwing an ambiguous reference error. Maybe I've misunderstood why this
error is thrown the few times I've seen it.

No ambiguity here. One of the Value(s) is sample.Texture.GLTexture.Value
and the other one is sample.Uniform.Value and the specs say the shortest
path wins.

-- 

-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] Expected ambigiuous reference error, got a value instead

[Daniel Skinner]

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

I ran into this today but don't understand why the compiler isn't throwing
an ambiguous reference error. Maybe I've misunderstood why this error is
thrown the few times I've seen it.

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

[go-nuts] How to determine the correct method signature to override fopen

[tonywalker . uk]

Hi,

I've been writing a shared-object which I'll use via LD_PRELOAD to override 
the open syscall. This is currently working OK but now I want to move on to 
fopen. I've defined it (as far as I can tell) in-line with the stdio header 
see here . However, when I try and 
build:

$ go build -buildmode=c-shared
# github.com/walkert/loader
In file included from 
$WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0:
./main.go:56:14: error: conflicting types for ‘fopen’
In file included from ./main.go:5:0,
 from $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
/usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was here
 extern FILE *fopen (const char *__restrict __filename,
  ^
/tmp/go-build775342366/github.com/walkert/loader/_obj/_cgo_export.c:17:7: 
error: conflicting types for ‘fopen’
 FILE* fopen(char* p0, char* p1)
   ^
In file included from ./main.go:5:0,
 from $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
/usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was here
 extern FILE *fopen (const char *__restrict __filename,
  ^

I've seen this before when I was trying to return an int instead of C.int 
so I have a feeling I'm missing something simple here. Any pointers would 
be much appreciated.

Thanks in advance!

-- 
You received this message because you are subscribed 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] is this code thread safety?

[Drew Derbyshire]

What Jan said.  I had started my own post before I realize other sane 
people checked in about the absurd colors.

On Thursday, November 2, 2017 at 3:13:07 AM UTC-7, Jan Mercl wrote:
>
> On Thu, Nov 2, 2017 at 6:54 AM sheepbao  
> wrote:
>
> > the close function is thread safety? how about call `closed` at the same 
> time. 
>
> I don't know, but you might want to reconsider posting text with contrast 
> going in some places below 10% (guestimated), to possibly get answers from 
> people which refuse to read what's not really readable.
>
> Black on white is the best.
>
> -- 
>
> -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: When should a RoundTripper close its connection?

[Frits van Bommel]

The best way is probably to replace the Response.Body before returning the 
result of http.ReadResponse() with an io.ReadCloser that also closes the 
underlying channel.

Replace the end of RoundTrip() with something like this (untested) code:
resp := http.ReadResponse(bufio.NewReader(ch), req)
resp.Body = channelCloser{ resp.Body, ch }
return resp
}

type channelCloser struct {
io.ReadCloser
ch ssh.Channel
}
func (cc *channelCloser) Close() error {
err := cc.ReadCloser.Close()
err2 := cc.ch.Close()
if err == nil {
err = err2
}
return err
}

This way the channel is closed when the body of the response is closed, and 
no sooner.

-- 
You received this message because you are subscribed 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 could a new user konw which packge should be used?

[Ian Lance Taylor]

On Thu, Nov 2, 2017 at 11:16 PM, 517 March  wrote:
> as a new Go programmer，
> how could I know which package should be use？
>
> is there any search tool could be used？
>
> or does it just depend on your  experience？

There is a search tool at https://godoc.org.

Ian

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

[go-nuts] Re: Go vendoring question

[Bobby M.]

Speaking as a new Gopher, but I have had lots of experience with software 
dependencies.  A tool like dep would be perfect for this. You could simply 
pin the one dependency until a fix is provided for the error, and for the 
others you can simply keep updating to the latest. 

This may not be the only time this happens and having the tools in place to 
handle it would make it very trivial to fix in the future.

-bobby

On Tuesday, October 31, 2017 at 11:43:21 AM UTC-7, Travis Keep wrote:
>
> Somebody I depend on for my project made a breaking change to their git 
> repo and broke my build.
>
> I found that if I simply revert their latest commit locally that my 
> project builds.  
>
> I don't necessarily want to vendor everything because most of the 
> libraries I use I trust. But I do want to vendor the one git repo whose 
> owner keeps making breaking changes. 
>
> I looked at dep, but dep seems to vendor everything. I don't want that. I 
> just want to vendor the one unstable library, and simply use HEAD for 
> everything else.
>
> What is the best way for me to proceed?  
>
> Thanks in advance,
>
>
>
>

-- 
You received this message because you are subscribed 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: appengine golang logs

[Jim Cote]

In appengine you have to use google.golang.org/appengine/log package.  The 
log calls must have a context passed to it.

See https://cloud.google.com/appengine/docs/standard/go/logs/reference.


On Friday, November 3, 2017 at 3:58:34 AM UTC-4, Sankar wrote:
>
> Hi
>
>
> I have a golang file where I have code like:
>
>
> log.Fatal("My error message: ", err)
>
>
> When the above statement is executed, In the appengine logviewer, I get 
> something like:
>
> panic: os.Exit called goroutine 1 [running]: 
> os.Exit(0x1)
> go/src/os/proc.go:58 
> 
>  
> +0x7c log.Fatal(0xc008549f60, 0x2, 0x2) 
> go/src/log/log.go:303 
> 
>  
> +0x79 main.main()
> main.go:42 
> 
>  
> +0x201
>
> But I dont get any error message. The main.go:42 corresponds to the 
> log.Fatal line in my code but I do not get to see the error message that is 
> printed as part of the log statement.
>
> I see that appengine package has a "Log" function which may print the 
> AppLogs such that they can be viewed from the Google Appengine log console 
> itself.
>
> My question is, can the golang default log package be somehow instructed 
> to redirect to appengine ? Something like:
>
> if env == "AppEngine" {
>   log.SetOutput(appengine.DefaultLogger) 
> }
>
> in my main file ? This way, I get to make my code not locked to google 
> cloud and also can deploy existing code which uses log already.
>
> Any pointers ?
>
> 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] is this code thread safety?

['Bryan Mills' via golang-nuts]

In general you can use the race detector to help answer this sort of 
question, although it does not detect all races.

Unfortunately, it doesn't detect this one. (I've 
filed https://golang.org/issue/22569, because I think it should.)

On Friday, November 3, 2017 at 4:08:19 AM UTC-4, sheepbao wrote:
>
> Thanks, I got it.
>
> On Friday, November 3, 2017 at 11:26:31 AM UTC+8, Jesse McNelis wrote:
>>
>> On Thu, Nov 2, 2017 at 4:54 PM, sheepbao  wrote: 
>> > 
>> > the close function is thread safety? how about call `closed` at the 
>> same 
>> > time. 
>>
>> It's not safe. Multiple goroutines can enter the 'default'  case in 
>> that select and close() the channel multiple times. 
>>
>> "Sending to or closing a closed channel causes a run-time panic." 
>> https://golang.org/ref/spec#Close 
>>
>

-- 
You received this message because you are subscribed 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 know if interface{} data is nil w/o reflecting?

[ojucie]

This thread helped me to understand better the current scenario and the 
implications of a future change.

I would be glad to recognize if this conversation had changed my mind, but 
it didn't.

Some programmers discovered that they could use this "valid nil interface" 
to do some smart tricks, as Jakob kindly has shown. While I do recognize 
that was indeed smart, Jakob offered another easy way of attaining the 
desired effect for his constructor. It would be pretty easy if he had to 
code that way to begin with.

I consider unfortunate the fact that I can't safely use an interface where 
previously I used a pointer. To me, at least, that is a natural 
evolutionary path for a piece of software as soon as the developer discover 
opportunities to leverage the commonality of an interface. I think such 
possibility would be more broadly useful than what we can do now.

Go has a bunch of interesting tricks and useful idioms, but this trick is 
proving costly.

Thanks to everyone.

-- 
You received this message because you are subscribed 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] cgo style question

[Andy Balholm]

Use the arr1 style when the length of the C array is known at compile time, and 
the arr2 style when it’s not known till runtime.

Andy

> On Nov 3, 2017, at 9:18 AM, DV  wrote:
> 
> Which "style" of wrapping a C array in a Go slice is more idiomatic in this 
> code - https://play.golang.org/p/6EbKl22MPQ - "arr1" or "arr2"? They both 
> seem to produce the exact same result.
> 
> I've seen the "arr2" style more often, but I don't understand why. The way I 
> wrapped "arr1" seems more clear to me - you have to know the length of the C 
> array, so why not just declare the pointer to the array with the correct 
> length to begin with? Why is the 1<<30 bit the more accepted style, e.g. here 
> - cgo 
> .  It 
> seems a bit noisy, especially with having to remember to put the length *and* 
> capacity when slicing the array.
> 
> I have a feeling I'm missing something important but I don't understand 
> what...
> 
> -- 
> You received this message because you are subscribed 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] cgo style question

[DV]

Which "style" of wrapping a C array in a Go slice is more idiomatic in this 
code - https://play.golang.org/p/6EbKl22MPQ - "arr1" or "arr2"? They both 
seem to produce the exact same result.

I've seen the "arr2" style more often, but I don't understand why. The way 
I wrapped "arr1" seems more clear to me - you have to know the length of 
the C array, so why not just declare the pointer to the array with the 
correct length to begin with? Why is the 1<<30 bit the more accepted style, 
e.g. here - cgo 
.  It 
seems a bit noisy, especially with having to remember to put the length 
*and* capacity when slicing the array.

I have a feeling I'm missing something important but I don't understand 
what...

-- 
You received this message because you are subscribed 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 could a new user konw which packge should be used?

[Tamás Gulácsi]

Use the standard library.

-- 
You received this message because you are subscribed 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 could a new user konw which packge should be used?

[517 March]

as a new Go programmer， 
how could I know which package should be use？

is there any search tool could be used？

or does it just depend on your  experience？

-- 
You received this message because you are subscribed 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] Issue with log.V and log.${Level}Depth

[Xiaoyi Shi]

Hi there,

When combining V() and ${Level}Depth() together, the logging logic becomes
less
clear. For instance, with the retry function below:

```go
func Retry(fn func() error) error {
  var lastErr error
  for attempt := 0; attempt < maxRetries; attempt++ {
backoff.Sleep(attempt)
if lastErr = fn(); lastErr == nil {
  return nil
}
// Determined by -vmodule set for retry().
if glog.V(1) {
  // Using caller info at 1 level up in the call stack.
  glog.WarningDepth(1, fmt.Sprintf("Attempt %d failed: %v", attempt,
lastErr))
}
  }
  if glog.V(1) {
glog.WarningDepth(1, fmt.Sprintf("Exhausted %d retries: %v",
maxRetries, lastErr))
  }
  return lastErr
}
```

In this example, Retry() as a helper function, which performs backoff
retries of fn().
It logs in case fn() fails, but instead of logging with context of Retry()
function,
using the context of the Retry() caller will provide better insights for
debugging.

When use ${Level}Depth() with V(), I would expect the verbose status is
determined while
aware of the depth set. So that -vmodule set for the Retry() caller should
be used for
determine the return value of V().

I propose adding a function called `VDepth(level, depth)`, so that the user
may
hint which caller to use.

Best,
Xiaoyi

-- 
You received this message because you are subscribed 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 know if interface{} data is nil w/o reflecting?

[Jakob Borg]

I often do nil checks on interfaces in places like constructors that may or may 
not have received optional parameters. In some cases as a parameter that may be 
nil if no implementation is required, in some cases where a functional option 
setting the interface was not given. Typically this looks something like:

func Walk(ctx context.Context, cfg Config) (chan protocol.FileInfo, error) {
w := walker{cfg}

if w.CurrentFiler == nil {
w.CurrentFiler = defaultCurrentFiler{}
}
…
}

where the field is set to some default implementation when nil. It’s also not 
uncommon to have nil implementations of that interface, especially in tests:

type mockCurrentFiler struct{}

func (*mockCurrentFiler) CurrentFile(string) whatever {
return nil
}

var testCurrentFiler *mockCurrentFiler // nil

…

cfg.CurrentFiler = testCurrentFiler // == nil in the new regime
Walk(ctx, cfg)

This would break, in a surprising way as the default implementation would be 
used instead of the given mock implementation. Clearly the test can be 
refactored:

cfg.CurrentFiler = {} // not nil

but yes, the change would break code.

I’m not saying that having this change in Go 2 would necessarily be a bad idea, 
but the current Go 1 behavior makes sense in Go 1 and there is definitely code 
that depends on it.

//jb

On 3 Nov 2017, at 11:09, oju...@gmail.com wrote:

Yes, Ayan, you are quite correct. There are a lot of comparisons to check if an 
error is nil. It has it's own FAQ entry: https://golang.org/doc/faq#nil_error

Sincerely, what I am after is an example of a situation where the solution 
proposed by Dave Cheney would create a problem, like "See here. In this 
situation the proposed change would break my code."

When comparing error to nil, Dave's change would work just fine. That FAQ entry 
would not be needed anymore.

On Friday, November 3, 2017 at 7:31:47 AM UTC-2, Ayan George wrote:


On 11/03/2017 05:23 AM, oju...@gmail.com wrote:
> Could somebody please point me to any example of comparing an
> interface to nil, in production code? Thanks.
>

Does checking if a variable of type error is nil count?

-ayan

--
You received this message because you are subscribed 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] Re: How to know if interface{} data is nil w/o reflecting?

[ojucie]

Yes, Ayan, you are quite correct. There are a lot of comparisons to check 
if an error is nil. It has it's own FAQ entry: 
https://golang.org/doc/faq#nil_error

Sincerely, what I am after is an example of a situation where the solution 
proposed by Dave Cheney would create a problem, like "See here. In this 
situation the proposed change would break my code."

When comparing error to nil, Dave's change would work just fine. That FAQ 
entry would not be needed anymore.

On Friday, November 3, 2017 at 7:31:47 AM UTC-2, Ayan George wrote:
>
>
>
> On 11/03/2017 05:23 AM, oju...@gmail.com  wrote: 
> > Could somebody please point me to any example of comparing an 
> > interface to nil, in production code? Thanks. 
> > 
>
> Does checking if a variable of type error is nil count? 
>
> -ayan 
>

-- 
You received this message because you are subscribed 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: How to know if interface{} data is nil w/o reflecting?

[Ayan George]

On 11/03/2017 05:23 AM, oju...@gmail.com wrote:
> Could somebody please point me to any example of comparing an
> interface to nil, in production code? Thanks.
> 

Does checking if a variable of type error is nil count?

-ayan

-- 
You received this message because you are subscribed 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: How to know if interface{} data is nil w/o reflecting?

[ojucie]

Could somebody please point me to any example of comparing an interface to 
nil, in production code? 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] is this code thread safety?

[sheepbao]

Thanks, I got it.

On Friday, November 3, 2017 at 11:26:31 AM UTC+8, Jesse McNelis wrote:
>
> On Thu, Nov 2, 2017 at 4:54 PM, sheepbao  
> wrote: 
> > 
> > the close function is thread safety? how about call `closed` at the same 
> > time. 
>
> It's not safe. Multiple goroutines can enter the 'default'  case in 
> that select and close() the channel multiple times. 
>
> "Sending to or closing a closed channel causes a run-time panic." 
> https://golang.org/ref/spec#Close 
>

-- 
You received this message because you are subscribed 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] appengine golang logs

[Sankar]

Hi


I have a golang file where I have code like:


log.Fatal("My error message: ", err)


When the above statement is executed, In the appengine logviewer, I get 
something like:

panic: os.Exit called goroutine 1 [running]: 
os.Exit(0x1)
go/src/os/proc.go:58 

 
+0x7c log.Fatal(0xc008549f60, 0x2, 0x2) 
go/src/log/log.go:303 

 
+0x79 main.main()
main.go:42 

 
+0x201

But I dont get any error message. The main.go:42 corresponds to the 
log.Fatal line in my code but I do not get to see the error message that is 
printed as part of the log statement.

I see that appengine package has a "Log" function which may print the 
AppLogs such that they can be viewed from the Google Appengine log console 
itself.

My question is, can the golang default log package be somehow instructed to 
redirect to appengine ? Something like:

if env == "AppEngine" {
  log.SetOutput(appengine.DefaultLogger) 
}

in my main file ? This way, I get to make my code not locked to google 
cloud and also can deploy existing code which uses log already.

Any pointers ?

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.