[go-nuts] Re: pkg-config sqlite3, Go sqlite3 code stop working after Go upgrade

[Tong Sun]

True -- it turns out that the github.com/mattn/go-sqlite3 was not installed 
properly and everything works fine after refreshing that.

Thanks Miki!

On Saturday, December 16, 2017 at 11:43:33 PM UTC-5, Miki Tebeka wrote:
>
> For some reason pkg-config doesn't know about sqlite3. It can be that 
> sqlite3 is not installed (or not installed properly).
>

-- 
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] goimports flag parity with gofmt

[ramyanexus]

Brad,

Would you be open to consider a PR to add the "-s" flag support to 
goimports?

On Monday, June 12, 2017 at 9:56:06 AM UTC-7, bradfitz wrote:
>
> Use the tool that does what you want.
>
> We don't have to put all functionality into all binaries.
>
> If vim-go makes assumptions that one helper binary does all functionality, 
> yes, please fix vim-go.
>
> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
> golan...@googlegroups.com > wrote:
>
>> This is still bothering us in 2017. I'd love to be able to run goimports 
>> on save in Vim, but also would like to simplify code (-s option). I use 
>> vim-go plugin, so I guess I can submit a pull request asking the plugin to 
>> run both commands on save, but I do not understand why the workaround 
>> instead of command parity? Is it something no one has had time to look into 
>> yet or is it too hard to implement with current goimports implementation?
>>
>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>>
>>> Oh, you did update goimports.
>>>
>>> gofmt and goimports both had their tab options removed.
>>>
>>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how 
>>> much it matters.  No editors really use those, do they?  If you want to do 
>>> it by hand, gofmt is still there.
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick  
>>> wrote:
>>>
 I don't think you're running the correct binary then, because:

 $ rm $(which goimports)
 $ go get -v -u code.google.com/p/go.tools/cmd/goimports
 $ goimports -h
 usage: goimports [flags] [path ...]
   -d=false: display diffs instead of rewriting files
   -e=false: report all errors (not just the first 10 on different lines)
   -l=false: list files whose formatting differs from goimport's
   -w=false: write result to (source) file instead of stdout



 On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov  
 wrote:

> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
> > You're running old binaries of each.
>
>
> Hmm. I'm try new goimports but nothing different:
>
> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
> code.google.com/p/go.tools (download)
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg pull
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg tags
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg branches
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg update default
> WORK=/tmp/go-build706264051
> code.google.com/p/go.tools/imports
> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
> mkdir -p $WORK/code.google.com/p/go.tools/
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
> /usr/lib64/go/pkg/tool/linux_amd64/6g 
> 
>  
> -o
> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
> code.google.com/p/go.tools/imports -complete -D
> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go ./imports.go
> ./sortimports.go ./zstdlib.go
> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
> $WORK/code.google.com/p/go.tools/imports.a
> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/
> code.google.com/p/go.tools/
> cp $WORK/code.google.com/p/go.tools/imports.a
> /home/vtolstov/devel/go/pkg/linux_amd64/
> code.google.com/p/go.tools/imports.a
> code.google.com/p/go.tools/cmd/goimports
> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/
> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/
> cd /home/vtolstov/devel/go/src/
> code.google.com/p/go.tools/cmd/goimports
> /usr/lib64/go/pkg/tool/linux_amd64/6g 
> 
>  
> -o
> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6 -p
> code.google.com/p/go.tools/cmd/goimports -complete -D
> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/cmd/goimports
> -I  $WORK -I
> /home/vtolstov/devel/go/pkg/linux_amd64 ./doc.go ./goimports.go
> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
> $WORK/code.google.com/p/go.tools/cmd/goimports.a
> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6
> cd .
> /usr/lib64/go/pkg/tool/linux_amd64/6l -o
> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/a.out -L $WORK
> -L /home/vtolstov/devel/go/pkg/linux_amd64
> $WORK/code.google.com/p/go.tools/cmd/goimports.a
> mkdir -p /home/vtolstov/bin/
> cp $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/a.out
> /home/vtolstov/bin/goimports 
>>

Re: [go-nuts] goimports flag parity with gofmt

[Brad Fitzpatrick]

I'd still rather not.

But it'd be more than one change anyway. We're not just going to copy/paste
the code from gofmt into goimports if it did happen. We'd want to move the
simplify code to an x/* package (either
https://godoc.org/golang.org/x/tools/go/ast/astutil or a subdirectory
thereof) and then use it from both goimports and gofmt, which would
additionally require vendoring the simplify package into std.




On Sat, Dec 16, 2017 at 8:50 PM,  wrote:

> Brad,
>
> Would you be open to consider a PR to add the "-s" flag support to
> goimports?
>
> On Monday, June 12, 2017 at 9:56:06 AM UTC-7, bradfitz wrote:
>>
>> Use the tool that does what you want.
>>
>> We don't have to put all functionality into all binaries.
>>
>> If vim-go makes assumptions that one helper binary does all
>> functionality, yes, please fix vim-go.
>>
>> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> This is still bothering us in 2017. I'd love to be able to run goimports
>>> on save in Vim, but also would like to simplify code (-s option). I use
>>> vim-go plugin, so I guess I can submit a pull request asking the plugin to
>>> run both commands on save, but I do not understand why the workaround
>>> instead of command parity? Is it something no one has had time to look into
>>> yet or is it too hard to implement with current goimports implementation?
>>>
>>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:

 Oh, you did update goimports.

 gofmt and goimports both had their tab options removed.

 But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
 much it matters.  No editors really use those, do they?  If you want to do
 it by hand, gofmt is still there.



 On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick 
 wrote:

> I don't think you're running the correct binary then, because:
>
> $ rm $(which goimports)
> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
> $ goimports -h
> usage: goimports [flags] [path ...]
>   -d=false: display diffs instead of rewriting files
>   -e=false: report all errors (not just the first 10 on different
> lines)
>   -l=false: list files whose formatting differs from goimport's
>   -w=false: write result to (source) file instead of stdout
>
>
>
> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
> wrote:
>
>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
>> > You're running old binaries of each.
>>
>>
>> Hmm. I'm try new goimports but nothing different:
>>
>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>> code.google.com/p/go.tools (download)
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg pull
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg tags
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg branches
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg update default
>> WORK=/tmp/go-build706264051
>> code.google.com/p/go.tools/imports
>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>> mkdir -p $WORK/code.google.com/p/go.tools/
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>> 
>> -o
>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>> code.google.com/p/go.tools/imports -complete -D
>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go
>> ./imports.go
>> ./sortimports.go ./zstdlib.go
>> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
>> $WORK/code.google.com/p/go.tools/imports.a
>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
>> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/code.google.com/p/go
>> .tools/
>> cp $WORK/code.google.com/p/go.tools/imports.a
>> /home/vtolstov/devel/go/pkg/linux_amd64/code.google.com/p/go
>> .tools/imports.a
>> code.google.com/p/go.tools/cmd/goimports
>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/
>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/cmd/g
>> oimports
>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>> 
>> -o
>> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6 -p
>> code.google.com/p/go.tools/cmd/goimports -complete -D
>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/cmd/goimports
>> -I  $WORK -I
>> /home/vtolstov/devel/go/pkg/linux_amd64 ./doc.go ./goimports.go
>> /

[go-nuts] Re: beginner : best way to learn go

[matthewjuran]

Effective Go (https://golang.org/doc/effective_go.html) covers most of it 
for new Go programmers experienced in other languages, then Google Search + 
stackoverflow.com, github.com issues, and golang-nuts answers most 
everything else in my experience.

I can't speak for beginner programmers but I would recommend Go as a first 
language.

Matt

On Saturday, December 16, 2017 at 5:36:58 PM UTC-6, Terry McKenna wrote:
>
> I've not read the book myself but it's a new title and might be worth the 
> $25: "Sams Teach Yourself Go in 24 hours"
>
> *"In just 24 sessions of one hour or less, Sams Teach Yourself Go in 24 
> Hours will help new and experienced programmers build software that’s 
> simpler, more reliable, and far more scalable. This book’s straightforward, 
> step-by-step approach guides you from setting up your environment through 
> testing and deploying powerful solutions."*
>
> ISBN-13: 978-0672338038 
> ISBN-10: 0672338033 
>
>
> On Saturday, January 17, 2015 at 4:15:08 AM UTC-5, Roelof Wobben wrote:
>
>> Hello, 
>>
>> I like to learn Go as a absolute beginner. 
>> What is the best way to learn it. I like to have many exercises because 
>> that is the best way I learn. 
>>
>> Second question :  Does anyone know if I can use Go on nitrious.io, or 
>> koding,com ? 
>>
>> Roelof
>>
>>

-- 
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] acceptance test-driven development

[Keith Brown]

Are there any tools written in go that are similar 
to http://robotframework.org/ ? I like Robotframe work because its simple 
to write test but the downside is I either need python or jre installed to 
run the tests. This is a burdon. 

Ideally, it would be great if there was a single binary I can run my tests 
against and I think go would be a great candidate for it. If anyone wants 
to work on something like this let me know I can contribute.

-- 
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 get nice html from godoc?

[jake6502]

Thanks Justin I will give it a try. 

(It certainly would be nice if "*godoc -html"* could be useful without 
having to modify the html.)


On Saturday, December 16, 2017 at 6:41:07 PM UTC-5, Justin Israel wrote:
>
>
>
> On Sun, Dec 17, 2017 at 5:47 AM > wrote:
>
>> I suspected it was something like that. I can muddle through, but HTML, 
>> and all that is not really my wheelhouse. Can you give me any more details? 
>>
>>
>>- Where can I find the correct "bundled css/js" files? 
>>
>> https://godoc.org/-/bootstrap.min.css
> https://godoc.org/-/site.css
>  
>
>>
>>- Where do I put them relative to the HTML file?
>>
>> That will be up to you, since you will need to actually format a 
> full-formed html file 
>
>>
>>-  Do I need to modify the HTML file to use them?
>>
>> Yea. The output from godoc -html is only a snippet. You would need to 
> inspect the source of godoc.org to see an example of what you would need 
> to do:
> view-source:https://godoc.org/os
>
> The css files are responsible for formatting the look of the page.
>  
>
>> Thanks
>>
>>   - Jake
>>
>> On Friday, December 15, 2017 at 5:23:59 PM UTC-5, Justin Israel wrote:
>>>
>>>
>>>
>>> On Fri, Dec 15, 2017, 7:35 AM  wrote:
>>>
 I run godoc like this:

  *godoc -html jake\tmp > doc.html* 

 When I open the resulting file (in Chrome or Firefox) the result look 
 terrible. The resulting file is attached. The collapsible sections display 
 as two separate items, are not collapsible, and in Firefox there are 
 strange characters instead of arrows. The preformed text blocks are hard 
 to 
 see, since they contain no special boarder or background and are not 
 indented. The links display all the time as "¶". Etc, etc. 

 So, how can I easily create and view documentation for my library that 
 looks more like the documentation at https://golang.org/pkg/ ?

 Thanks.

>>>
>>> It's because you are missing the css/js files that godoc pages use. In 
>>> my studio build system, for the godoc support in our Go plugin, I have it 
>>> deploying docs with the bundled css/js 
>>>
>> -- 
 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...@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...@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 Generate Vs Go Build!

[Compiler]

Hello,

Go Generate Vs Go Build!?!

guest@Base:~/Gits/go-hello$ ls
hello  hello.go
guest@Base:~/Gits/go-hello$ cat hello.go
package main

import "fmt"

func main() {
fmt.Println("Hello, World")
}

guest@Base:~/Gits/go-hello$ go build hello.go
guest@Base:~/Gits/go-hello$ go generate hello.go
guest@Base:~/Gits/go-hello$ ./hello
Hello, World

-- 
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 Generate Vs Go Build!

[Compiler]

- https://en.wikipedia.org/wiki/Go_(programming_language)
- go build, which builds Go binaries using only information in the source 
files themselves, no separate makefiles
- go test, for unit testing and microbenchmarks
- go fmt, for formatting code
- go get, for retrieving and installing remote packages
- go vet, a static analyzer looking for potential errors in code
- go run, a shortcut for building and executing code
- godoc, for displaying documentation or serving it via HTTP
- gorename, for renaming variables, functions, and so on in a type-safe way
- go generate, a standard way to invoke code generators

Please explain me.


On Monday, December 18, 2017 at 1:03:55 AM UTC+3:30, Compiler wrote:
>
> Hello,
>
> Go Generate Vs Go Build!?!
>
> guest@Base:~/Gits/go-hello$ ls
> hello  hello.go
> guest@Base:~/Gits/go-hello$ cat hello.go
> package main
>
> import "fmt"
>
> func main() {
> fmt.Println("Hello, World")
> }
>
> guest@Base:~/Gits/go-hello$ go build hello.go
> guest@Base:~/Gits/go-hello$ go generate hello.go
> guest@Base:~/Gits/go-hello$ ./hello
> Hello, World
>
>

-- 
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 Generate Vs Go Build!

[Ain]

On Sunday, December 17, 2017 at 11:45:12 PM UTC+2, Compiler wrote:
>
> - https://en.wikipedia.org/wiki/Go_(programming_language)
> - go build, which builds Go binaries using only information in the source 
> files themselves, no separate makefiles
> - go test, for unit testing and microbenchmarks
> - go fmt, for formatting code
> - go get, for retrieving and installing remote packages
> - go vet, a static analyzer looking for potential errors in code
> - go run, a shortcut for building and executing code
> - godoc, for displaying documentation or serving it via HTTP
> - gorename, for renaming variables, functions, and so on in a type-safe 
> way
> - go generate, a standard way to invoke code generators
>
> Please explain me.
>

Have you seen https://golang.org/cmd/go/


HTH
ain

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

Re: [go-nuts] Elphaba Chess

[matthewjuran]

Here's a GPL Go chess library: https://github.com/dylhunn/dragontoothmg

And a project without license: https://github.com/kjda/chess-on-go

And a GPL Go chess server with HTML 
interface: https://github.com/jonpchin/gochess

Matt

On Saturday, December 9, 2017 at 8:38:41 PM UTC-6, Hugh Aguilar wrote:
>
>
>
> On Friday, December 8, 2017 at 11:55:15 PM UTC-7, Filip Zaludek wrote:
>>
>>
>> https://chessprogramming.wikispaces.com/Alpha-Beta
>
>
> Thanks for the link. I read through a lot of the pages. I did find one 
> page that addressed the part I don't understand:
> https://chessprogramming.wikispaces.com/Quiescence+Search
> I'm still pretty fuzzy on it --- the horizon effect is what I had trouble 
> with in my Reversi program.
>
> The whole thing is quite complicated. Writing a chess program is really a 
> bigger project than I want to undertake.
> My Elphaba Chess is similar enough to regular chess that I should be able 
> to just modify an existing program without really understanding it.
> That is what I'm going to try. Programming without thinking! I won't be 
> the first. ;-)
>
>

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

[go-nuts] Re: Go Generate Vs Go Build!

[Dave Cheney]

https://blog.golang.org/generate

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

Re: [go-nuts] Elphaba Chess

[hughaguilar96]

On Sunday, December 17, 2017 at 4:41:19 PM UTC-7, matthe...@gmail.com wrote:
>
> Here's a GPL Go chess library: https://github.com/dylhunn/dragontoothmg
>
> And a project without license: https://github.com/kjda/chess-on-go
>
> And a GPL Go chess server with HTML interface: 
> https://github.com/jonpchin/gochess
>
> Matt
>

Thanks for the links --- I'll look into those. :-)

-- 
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 can I get unix timestamp(time.Now().Unix()) in linker(cmd/link)

[Ally Dale]

Thanks a lot, but I tried to pass timestamp by 
"-X=runtime.buildtimestamp=" to linker, it fails with the same message.
I guess the timestamp makes the dependence packages always STALE, maybe I 
have to check logic of command "go list".

 

在 2017年12月16日星期六 UTC+8上午5:11:00，Ian Lance Taylor写道：
>
> On Fri, Dec 15, 2017 at 3:08 AM, Ally  Dale  > wrote: 
> > Hi all, 
> > I just need a function to report the timestamp when my app compiled. 
> > 
> > func main() { 
> > 
> > 
> > unix := runtime.BuildTimestamp() 
> > 
> > 
> > t := time.Unix(unix, 0) 
> > 
> > 
> > println("hello world") 
> > 
> > 
> > println("buildtimestamp:", unix) 
> > 
> > 
> > println("buildtime :", t.String()) 
> > 
> > 
> > // Output: 
> > 
> > 
> > // hello world 
> > 
> > 
> > // buildtimestamp: 1513329454 
> > 
> > 
> > // buildtime : 2017-12-15 17:17:34 +0800 CST 
> > 
> > 
> > } 
> > 
> > 
> > 
> > [runtime.BuildTimestamp()](
> https://github.com/vipally/go/blob/ally_build_time/src/runtime/symtab.go#L399)
>  
>
> > use a variable defined in 
> > [runtime.firstmoduledata.buildtimestamp](
> https://github.com/vipally/go/blob/ally_build_time/src/runtime/symtab.go#L372)
>  
>
> > which will be written by 
> > [cmd/link](
> https://github.com/vipally/go/blob/ally_build_time/src/cmd/link/internal/ld/symtab.go#L562)
>  
>
> > 
> > My trouble is, if cmd/link use time.Now().Unix() to get unix timestamp, 
> it 
> > will make a new dependence of time for cmd/link. 
> > And this dependence will cause a STALE error when go_bootstrap building. 
> > go tool dist: unexpected stale targets reported by 
> > E:\go\pkg\tool\windows_amd64\go_bootstrap list -gcflags="" -ldflags="" 
> > for [cmd/asm cmd/cgo cmd/compile cmd/link runtime/internal/sys]: 
> > STALE cmd/asm: stale dependency: runtime/internal/atomic 
> > STALE cmd/cgo: stale dependency: runtime/internal/atomic 
> > STALE cmd/compile: stale dependency: runtime/internal/atomic 
> > STALE cmd/link: stale dependency: runtime/internal/atomic 
> > STALE runtime/internal/sys: build ID mismatch 
> > 
> > 
> > So, my question is, if I cannot use time.Now().Unix() or runtime.now() 
> to 
> > get unix timestamp in cmd/link. How can I get unix timestamp in 
> > linker(cmd/link)? 
>
> Use something like -ldflags=-X=`VAR=date`.  The -X option is 
> documented at https://golang.org/cmd/link. 
>
> 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: Surprise About How Method Receivers Work

[Jeff Goldberg]

On Sunday, December 17, 2017 at 2:32:24 PM UTC-6, jlfo...@berkeley.edu 
wrote:

>
> Here's something that someone new to Go might run up against. I know I did.
>
>
Me, too! 

The trivial program below, derived from "The Go Programming Language"
> book, shows two methods that differ only in the way they treat their
> receiver. In the first, the receiver is a pointer to a slice, and in the
> second, the receiver is a slice. So far so good. What confused me is
> that both methods return the same result even when called the same way.
> I would have expected only one of the methods to work.
>
>
I never really figured out what was going on, but I finally just accepted 
it as "go is doing
what I want it to do, even if I say it wrong." 

Here's what I believe is the explanation. The book says (slightly
> edited) "If the receiver p is a variable of type Path but the method
> requires a *Path receiver, we can use this shorthand:
>
> p.pr1()
>
> and the compiler will perform an implicit &p on the variable.". This
> explains what happens when pr1() is called.
>
>
Right. I guess this all works because there are so few things you can do 
with pointers; so this
isn't going to create odd ambiguities.
 

> I'm surprised that Go would include this implicit behavior because type
> conversions are generally required to be explicit.
>
>
I agree that it seems un-Go-like initially. But the more I think about it, 
the more it makes sense given
other restrictions on pointers. The only thing you can do with pointers is 
pass them and
deferences them. You never actually do anything with the value of the 
pointer itself. A type can have
methods, but a pointer to a type can't. So it's always(?) going to be safe 
for the compiler to do this.

Of course you don't want people using both forms within a local scope. So 
that is my guess at
why the this "shortcut" is allowed only via receivers.

I am, of course, speculating wildly. I would be pleased to be set straight 
by the people who actually
know what is going on.

And I pray to whatever is holy that I never take the habits I'm picking up 
with this back to C.

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