Re: [go-nuts] Possible to make go not touch the built file if it builds purely from cache?

[Glen Huang]

Thanks, as mentioned in the previous reply, this is what I end up using.

On Thursday, April 16, 2020 at 10:25:03 AM UTC+8, Shulhan wrote:
>
>
> > On 15 Apr 2020, at 18.55, Glen Huang > 
> wrote: 
> > 
> > I have a makefile where upon a new go binary being built, it builds some 
> other stuff that is not go related. 
> > 
> > The go binary is unconditionally built with a FORCE prerequisite, so the 
> go build command always runs, but that command always updates the output 
> binary, which leads to downstream being unnecessarily built. 
> > 
> > Is there a way to tell go not to touch the output file if it builds 
> purely from the cache? 
> > 
> > Currently it prevents me from using a makefile, and I don't really feel 
> like sidestepping go's cache system by manually listing all go files and 
> have the makefile functions as a cache, besides, it's really difficult to 
> correctly list dependencies if the module is big and the binary being built 
> only depends on a subset. 
> > 
>
> If the source code is not large enough, I think this will works, 
>
> ``` 
> CMD_SRC   :=$(shell go list -f '{{ $$dir := .Dir }}{{ range 
> .GoFiles }} {{ $$dir }}/{{.}} {{end}}' $(CMD_DIR)) 
>
> your/binary: $(CMD_SRC) 
> go build ./cmd/binary 
> ```

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d0bc8e99-5e85-4c16-87b6-0b663c6cd9a1%40googlegroups.com.

Re: [go-nuts] Possible to make go not touch the built file if it builds purely from cache?

[Personal]

> On 15 Apr 2020, at 18.55, Glen Huang  wrote:
> 
> I have a makefile where upon a new go binary being built, it builds some 
> other stuff that is not go related.
> 
> The go binary is unconditionally built with a FORCE prerequisite, so the go 
> build command always runs, but that command always updates the output binary, 
> which leads to downstream being unnecessarily built.
> 
> Is there a way to tell go not to touch the output file if it builds purely 
> from the cache?
> 
> Currently it prevents me from using a makefile, and I don't really feel like 
> sidestepping go's cache system by manually listing all go files and have the 
> makefile functions as a cache, besides, it's really difficult to correctly 
> list dependencies if the module is big and the binary being built only 
> depends on a subset. 
> 

If the source code is not large enough, I think this will works,

```
CMD_SRC   :=$(shell go list -f '{{ $$dir := .Dir }}{{ range .GoFiles }} 
{{ $$dir }}/{{.}} {{end}}' $(CMD_DIR))

your/binary: $(CMD_SRC)
go build ./cmd/binary
```

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2C480CE6-CF9A-42FF-B1C5-CA5CE8517055%40gmail.com.

Re: [go-nuts] Possible to make go not touch the built file if it builds purely from cache?

[Glen Huang]

I end up using "go list" to list dependencies, and rely on the makefile to 
cache builds, for the binary runs in docker and the host machine is a Mac, 
and cross compiling with race detector enable doesn't seem to easy in this 
case. Previously I had to give race detector up to use go build directly.

move-if-change sounds like a good approach, will come in handy when there 
is no need to cross compile, thanks for the tip.

On Thursday, April 16, 2020 at 4:09:27 AM UTC+8, Ian Lance Taylor wrote:
>
> On Wed, Apr 15, 2020 at 4:55 AM Glen Huang > 
> wrote: 
> > 
> > I have a makefile where upon a new go binary being built, it builds some 
> other stuff that is not go related. 
> > 
> > The go binary is unconditionally built with a FORCE prerequisite, so the 
> go build command always runs, but that command always updates the output 
> binary, which leads to downstream being unnecessarily built. 
> > 
> > Is there a way to tell go not to touch the output file if it builds 
> purely from the cache? 
> > 
> > Currently it prevents me from using a makefile, and I don't really feel 
> like sidestepping go's cache system by manually listing all go files and 
> have the makefile functions as a cache, besides, it's really difficult to 
> correctly list dependencies if the module is big and the binary being built 
> only depends on a subset. 
>
> Updating the binary is intentional, so that `go build` has consistent 
> behavior. 
>
> The way to handle this in a Makefile is to use the move-if-change 
> dance, which looks more or less like 
>
> real-target: stamp-target; @true 
> stamp-target: ... 
> go build -o temporary-target ... 
> if cmp temporary-target real-target; then \ 
> rm temporary-target; \ 
> else \ 
> mv temporary-target real-target 
> fi 
> touch stamp-target 
>
> With this technique stamp-target will be rebuilt if any of its 
> dependencies change, and real-target will be rebuilt only if the build 
> generated a file that was different in some way. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/31a4ac61-69d7-4891-8b54-67fb22e082ce%40googlegroups.com.

[go-nuts] How to use plugin package to do livereload?

[aihui zhu]

my program and plugin shares some common package, i'm temporarily copy the 
plugin's main package to main_$timestamp, 
so i can avoid same pluginpath and load it many times.

but it doesn't works for some problems:
if i changes only structure method, because of type equal, the runtime 
still refers to the old type, the new function will never be run.
if i change the structure members, the plugin was failed to load for error 
'plugin was built with a different version'

i'm thinking another way: could i change the plugin's module name to 
module_$timestamp before go build, so the plugin doesn't shares package 
with main program?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8a004129-e649-4d2a-a4a9-e20cbdd1858b%40googlegroups.com.

Re: [go-nuts] x/text: Interest in Unicode text segmentation?

[Ian Lance Taylor]

[ +mpvl ]

On Wed, Apr 15, 2020 at 2:30 PM Matt Sherman  wrote:
>
> Hi, I am working on a tokenizer based on Unicode text segmentation (UAX 29). 
> I am wondering if there would be an interest in adding range tables for word 
> break categories to the x/text or unicode packages. It appears they could be 
> code-gen’d alongside the rest of the range tables.
>
> Pardon if this is already being done and I have missed it. I see some mention 
> of those categories (e.g. ALetter) in other places.
>
> My code is here. 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/2a058556-da51-46d0-a41b-28e323541332%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXiKgZTi4RdgB2ZZAC1cKJ3A1dVsweDULCM2gf8g1SUEw%40mail.gmail.com.

[go-nuts] x/text: Interest in Unicode text segmentation?

[Matt Sherman]

Hi, I am working on a tokenizer based on Unicode text segmentation (UAX 29 
). I am wondering if 
there would be an interest in adding range tables for word break categories 
 to 
the x/text or unicode packages. It appears they could be code-gen’d 
alongside the rest of the range tables.

Pardon if this is already being done and I have missed it. I see some 
mention  of 
those categories (e.g. ALetter) in other places.

My code is here . 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2a058556-da51-46d0-a41b-28e323541332%40googlegroups.com.

Re: [go-nuts] Possible to make go not touch the built file if it builds purely from cache?

[Ian Lance Taylor]

On Wed, Apr 15, 2020 at 4:55 AM Glen Huang  wrote:
>
> I have a makefile where upon a new go binary being built, it builds some 
> other stuff that is not go related.
>
> The go binary is unconditionally built with a FORCE prerequisite, so the go 
> build command always runs, but that command always updates the output binary, 
> which leads to downstream being unnecessarily built.
>
> Is there a way to tell go not to touch the output file if it builds purely 
> from the cache?
>
> Currently it prevents me from using a makefile, and I don't really feel like 
> sidestepping go's cache system by manually listing all go files and have the 
> makefile functions as a cache, besides, it's really difficult to correctly 
> list dependencies if the module is big and the binary being built only 
> depends on a subset.

Updating the binary is intentional, so that `go build` has consistent behavior.

The way to handle this in a Makefile is to use the move-if-change
dance, which looks more or less like

real-target: stamp-target; @true
stamp-target: ...
go build -o temporary-target ...
if cmp temporary-target real-target; then \
rm temporary-target; \
else \
mv temporary-target real-target
fi
touch stamp-target

With this technique stamp-target will be rebuilt if any of its
dependencies change, and real-target will be rebuilt only if the build
generated a file that was different in some way.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUP2vWJRapdzE32S78B36f%2B7ve%3DNNOVnziBXutxTv%3Ds7g%40mail.gmail.com.

[go-nuts] "Go build failed." in Go tour requires explicit Kill

[Marvin Renich]

In the Go tour, what is the purpose of requiring the user to explicitly
press the "Kill" button when the build fails?  This seems completely
unnecessary to me.

If this is just a natural consequence of the internal implementation, it
would, in my opinion, be well worth the effort to make a failed build
exit without requiring the user to press "Kill".

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200415170159.k57ltq44otwmwfqz%40basil.wdw.

[go-nuts] Re: Writing data without synchronization

[Jake Montgomery]

On Tuesday, April 14, 2020 at 7:38:44 AM UTC-4, Slawomir Pryczek wrote:
>
> Hi Guys, was wondering about some things related to multithread code.
>
> 2. For lazy initialization double-check pattern. I found on several 
> sources that it is safe, still race detector complains about data races 
> (which is correct because there is race, which is done on purpose) - 
> https://software.intel.com/en-us/node/506123
> And of course this code seems to be working as expected
>
> https://play.golang.org/p/gUzWHr-1K9H
>

It is a race. Your code may 'seem' safe, and it may always work correctly 
on some processor and Go version combinations. But it also might work *some 
of the time* on some processor and Go version combinations, but fail in 
unexpected and hard to debug ways other times. I always like to suggest 
reading Benign Data Races: What Could Possibly Go Wrong 

 
in cases like this. (It is from the same site you reference.) 

Be very careful with concurrency. Just because you found "several sources 
that it is safe", does not mean that it is. Even if it is safe in the case 
the article sites, the devil is always in the details with concurrency. It 
may be safe in C++, with its memory model, and guarantees, but that does 
not necessarily mean it is safe in another language, such as Go. Also, the 
article you reference (https://software.intel.com/en-us/node/506123)  uses 
a *tbb::atomic*, which is not not a go type. In your example you use a 
*bool 
*instead. Details. Also, the documentation specifically says that the 
example in the article only works on Intel processors, so even in C++, it 
would be unsafe for that code to run on processors.

One final note on this kind of optimization. Sometimes the Go runtime or 
even standard libraries play such 'crazy games'. Do not be fooled, it is ok 
for them to do it, but not for us. The runtime and libraries are aware of 
what processor they are running on (if necessary), and are tied to a 
specific version of Go. If the language internals change in a way that 
breaks their 'crazy games', they can fix them at the same time. We do not 
have that luxury. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cdf346cc-ab71-4080-9022-f99f8e91e6c9%40googlegroups.com.

[go-nuts] wording in Go tour, methods/19

[Marvin Renich]

In the Go tour at https://tour.golang.org/methods/19 it says

  The error type is a built-in interface similar to fmt.Stringer:

The words closest to "similar to" are "built-in interface", implying
that the way error is similar to fmt.Stringer is that it is a built-in
interface, which it clearly isn't.  I would be surprised if this is not
a source of confusion to a significant number of programmers who are new
to go and using the tour to get acquainted.

A much better wording would be

  The error type is a built-in interface; its definition is similar to
  fmt.Stringer:

I don't have a github account, so I can't send feedback using the
feedback button on the page.

...Marvin

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200415155719.ushmx5idhyid4vnw%40basil.wdw.

[go-nuts] Re: Possible to make go not touch the built file if it builds purely from cache?

[Brian Candler]

Not answering your question directly, but some large projects (e.g. gVisor 
) are using bazel, which may 
solve this for you.  Specifically supports multi-language builds.
https://bazel.build/

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d9af3e8b-6197-4b47-838e-7ae8d84913ec%40googlegroups.com.

[go-nuts] Possible to make go not touch the built file if it builds purely from cache?

[Glen Huang]

I have a makefile where upon a new go binary being built, it builds some 
other stuff that is not go related.

The go binary is unconditionally built with a FORCE prerequisite, so the go 
build command always runs, but that command always updates the output 
binary, which leads to downstream being unnecessarily built.

Is there a way to tell go not to touch the output file if it builds purely 
from the cache?

Currently it prevents me from using a makefile, and I don't really feel 
like sidestepping go's cache system by manually listing all go files and 
have the makefile functions as a cache, besides, it's really difficult to 
correctly list dependencies if the module is big and the binary being built 
only depends on a subset. 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/edca0a5c-7ed0-4631-900c-9df818b41263%40googlegroups.com.

[go-nuts] Re: Json Decode Failed

[Ali Hassan]

This is not possible because this project is very large 

On Tuesday, April 14, 2020 at 7:34:49 PM UTC+5, Brian Candler wrote:
>
> Can you make this as a full runnable example on play.golang.org ?
>
> What type is a "db.Visitor"?
>
> When I compile my code it throw error like this 0xc54f40 , 0xc32070.
>>
>
> It will show more than that.  Please show the complete error message. 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5960fc28-d309-4d06-9ea5-7d4ae85b8649%40googlegroups.com.

[go-nuts] Re: Json Decode Failed

[Ali Hassan]

I try and Thank you for help

On Tuesday, April 14, 2020 at 6:53:32 PM UTC+5, Ali Hassan wrote:
>
> dec :=json.NewDecoder(request.Body)//ok
> var  visitor  db.Visitor 
> err :=  dec.Decode();if err!= nil{ print("error", err) // throw 
> this error } println("data:", visitor.Id)
>
> When I compile my code it throw error like this 0xc54f40 , 0xc32070. 
> Please help me
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/375aa887-ebda-4394-bc45-331e9fa529a8%40googlegroups.com.

Re: [go-nuts] Re: Json Decode Failed

[roger peppe]

I suspect your client isn't providing the required JSON body when making
the request. Try reading the body with `ioutil.ReadAll` before decoding
with `json.Unmarshal` so you can see exactly what's being provided.


On Wed, 15 Apr 2020 at 09:40, Ali Hassan  wrote:

> So i will try with printf statement, to checkout what's the error , i had
> ...
> Error : EOF
>
> On Tuesday, April 14, 2020 at 6:53:32 PM UTC+5, Ali Hassan wrote:
>>
>> dec :=json.NewDecoder(request.Body)//ok
>> var  visitor  db.Visitor
>> err :=  dec.Decode();if err!= nil{ print("error", err) // throw
>> this error } println("data:", visitor.Id)
>>
>> When I compile my code it throw error like this 0xc54f40 , 0xc32070.
>> Please help me
>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/ac63cb0b-b640-49cb-a833-ae698f2c7e19%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJhgachraRU7c2TpHgZ5YtZbVhVFF-NHNAourVxPAsSn_4ZAgQ%40mail.gmail.com.

[go-nuts] Re: Json Decode Failed

[Ali Hassan]

So i will try with printf statement, to checkout what's the error , i had 
...
Error : EOF

On Tuesday, April 14, 2020 at 6:53:32 PM UTC+5, Ali Hassan wrote:
>
> dec :=json.NewDecoder(request.Body)//ok
> var  visitor  db.Visitor 
> err :=  dec.Decode();if err!= nil{ print("error", err) // throw 
> this error } println("data:", visitor.Id)
>
> When I compile my code it throw error like this 0xc54f40 , 0xc32070. 
> Please help me
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ac63cb0b-b640-49cb-a833-ae698f2c7e19%40googlegroups.com.