Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Tue, Feb 27, 2018 at 8:17 AM wrote: > ok, this is really make gophers worry about whether or not the pointer atomic functions should be used. What to worry about? Under the Go 1 compatibility promise, the sync/atomic package is going nowhere, IIUC. -- -j -- You received this message beca

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 11:21:43 PM UTC-5, Ian Lance Taylor wrote: > > On Mon, Feb 26, 2018 at 7:20 PM, > > wrote: > > > > On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor > wrote: > >> > >> On Mon, Feb 26, 2018 at 9:42 AM, wrote: > >> > > >> > On Monday, Febr

[go-nuts] [ANN] Go Israel Meetup - Thu, March 8, 2018

Hi, If you're around and interested, our next Go Israel meetup on on Thu, March 8, 2018. 6pm at Google campus Tel Aviv. We'll have two talks: - From zero to access token by Roy Segall - gRPC by Almog Baku See more at https://www.meetup.com/Go-Israel/events/kjvczlyxfbkb/ See you there, -- Miki

[go-nuts] Re: Cannot take the adress of.....

Thank you Sir 2018. február 27., kedd 5:56:57 UTC+1 időpontban k1at...@gmail.com a következőt írta: > > Hi > > I have seen this example somewhere but i modified it : > > package main > > import "fmt" > > type notifier interface { > notify() > } > > type duration int > > func (d *duration) notif

Re: [go-nuts] Re: Cannot take the adress of.....

On Tue, Feb 27, 2018 at 4:01 PM, wrote: > var j int = 42 > var p *int > p=&int(j) //this doesn't work > fmt.Println(*p) > Yep, this is true. You can't take the address of the return value of a function or a conversion (which is conceptually just a function) because it doe

[go-nuts] Re: Cannot take the adress of.....

or similar simpler example : this works : var j int = 42 var p *int p=&j // this works fmt.Println(*p) var j int = 42 var p *int p=&int(j) //this doesn't work fmt.Println(*p) 2018. február 27., kedd 5:56:57 UTC+1 időpontban k1at..

[go-nuts] Cannot take the adress of.....

Hi I have seen this example somewhere but i modified it : package main import "fmt" type notifier interface { notify() } type duration int func (d *duration) notify() { fmt.Println("Sending Notification in", *d) } func main() { var n notifier var i int = 42 n = &duration(i) n.notify() } b

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Mon, Feb 26, 2018 at 7:20 PM, wrote: > > On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor wrote: >> >> On Mon, Feb 26, 2018 at 9:42 AM, wrote: >> > >> > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: >> >> >> >> On 26 Feb 2018, at 18:21, "di...@veryhah

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 2:24:39 PM UTC-5, Ian Lance Taylor wrote: > > On Mon, Feb 26, 2018 at 9:42 AM, > > wrote: > > > > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: > >> > >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com" > wrote: > >> > >> On Monday, F

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

I went ahead and optimistically filed https://github.com/golang/go/issues/24142. On Mon, Feb 26, 2018 at 2:35 PM, Caleb Spare wrote: > I think that CL that would have helped me realize it was (probably) > time.Now sooner. It certainly seems like a Pareto improvement. > > However: > > (1) I don't

[go-nuts] Re: How to merge labels along with json responses

The general pattern for this is: 1. Create a data structure that reflects the JSON you want. 2. Fill it with data 3. Marshal or Encode Since you have an example of the JSON you want, putting it through one of the tools from Generating Go structs from JSON

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

I think that CL that would have helped me realize it was (probably) time.Now sooner. It certainly seems like a Pareto improvement. However: (1) I don't think that most Go developers know what _VDSO is any more than they know what _ExternalCode is, so it probably won't substantially help most ppro

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

On Mon, Feb 26, 2018 at 12:55 PM, Ian Lance Taylor wrote: > On Sun, Feb 25, 2018 at 8:04 PM, Dave Cheney wrote: > >> I don't understand how that could happen. time.Now calls time.now (which >> is in assembly) so the former shouldn't be inlined, or omitted from >> profiling. >> > > > But on amd64

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

Ahh, thank you. That was the missing piece of my understanding. -- 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 mor

Re: [go-nuts] How to interpret runtime._ExternalCode in a profile?

On Sun, Feb 25, 2018 at 8:04 PM, Dave Cheney wrote: > I don't understand how that could happen. time.Now calls time.now (which > is in assembly) so the former shouldn't be inlined, or omitted from > profiling. > But on amd64 GNU/Linux time.Now is implemented by calling into the VDSO. And it's t

Re: [go-nuts] NOSPLIT on Go assembler defined functions

Thank you very much Ian, I didn't notice the imported headers file in the examples I was looking at. My code is compiling perfectly fine after I added that line. Cheers, Pablo On Tue, Feb 27, 2018 at 8:46 AM, Ian Lance Taylor wrote: > On Sun, Feb 25, 2018 at 11:27 PM, Pablo Rozas Larraondo > w

Re: [go-nuts] NOSPLIT on Go assembler defined functions

On Sun, Feb 25, 2018 at 11:27 PM, Pablo Rozas Larraondo wrote: > > I started learning about Go assembler and I'm having problems with the > NOSPLIT symbol, which makes the compilation fail with error message: > "illegal or missing addressing mode for symbol NOSPLIT" > > I've found a blog post whic

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Mon, Feb 26, 2018 at 9:42 AM, wrote: > > On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: >> >> On 26 Feb 2018, at 18:21, "di...@veryhaha.com" wrote: >> >> On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: >>> >>> On 26 Feb 2018, at 16:38, di...@veryhaha

[go-nuts] Re: http client for go-server-timing

Thanks for the CR Matt, that's very kind of you. About the factory, I thought that some of the options would be sometimes easier to define in construction time, and copy the object doesn't add complexity to my opinion. About two sets of optoins, except of the "WithName" option, there is no "ti

Re: [go-nuts] Vgo and reproducable builds

On Mon, Feb 26, 2018 at 8:29 AM, Johann Höchtl wrote: > > Right at the beginning of the first post about vgo it is stated: > >> Versioning will also let us ensure that a program builds exactly the same >> way tomorrow as it does today. Even when there are newer versions of my >> dependencies, th

[go-nuts] Why does crypto/rand expose Reader?

crypto/rand exposes an io.Reader variable Reader as "a global, shared instance of a cryptographically strong pseudo-random generator." Furthermore, crypto/rand.Read implicitly uses Reader for its crypto source. This seems problematic to me because then any package can just overwrite crypto/rand.Re

[go-nuts] Organizing code with vgo

When writing go code with one package and one command I would structure it like package.go ./cmd/command1/main.go With package.go being at the root of the workspace and ./cmd/command1/main.go naming an executable which primarily make use of the package. Now I _migh_ have vendored package.go w

[go-nuts] golang-nuts archive is available

Dear gophers, I am happy to announce that there is an (unofficial) dataset with all the messages posted in this group since the very beginning: https://www.kaggle.com/vmarkovtsev/gonuts I encourage data scientists and ML engineers who use Go to play with it. Here is a list of sample problems w

[go-nuts] Re: Why does ioutil/TempFile take a prefix instead of a suffix?

In case anyone stumbles across this thread, here's a tempfile library that supports file suffix: https://github.com/tink-ab/tempfile Also, if you'd like to track this upstream in Golang standard library, you can do that here: https://github.com/golang/go/issues/4896 Cheers, Jens On Monday, May

[go-nuts] How to merge labels along with json responses

can anyone help me to merge labels along with the JSON responses I have my code: https://play.golang.org/p/DB0S4byIHnc and response: https://play.golang.org/p/y7OOYB1h5z_C but I don't know to print JSON responses like the below one (expected output ): https://play.golang.org/p/ejOJeT

[go-nuts] Re: vgo and handling major versions

+1 I love gopkg.in and use it extensively - gopkg.in + tags + GOPATH is my happy combination. On Monday, February 26, 2018 at 1:11:21 PM UTC+3:30, Maxim Ivanov wrote: > > gopkg.in already "redirects" different import paths to different > branches in your repo. You then use correct module name

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 12:35:13 PM UTC-5, Jakob Borg wrote: > > On 26 Feb 2018, at 18:21, "di...@veryhaha.com " < > di...@veryhaha.com > wrote: > > On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: > <#34A5B26F-AB6C-4559-A17D-D8137AC52784@kastelo.net_> > <#34A5B26F-A

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On 26 Feb 2018, at 18:21, "d...@veryhaha.com" mailto:d...@veryhaha.com>> wrote: On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: Will the "sync/atomic" package get broken? This atomic package import

Re: [go-nuts] Is there some kind of memory write protection mechanism?

So, the sync/atomic package is possible to break tomorrow? On Monday, February 26, 2018 at 12:24:35 PM UTC-5, Andy Balholm wrote: > > Oops. I left out a couple words. I meant “does not keep”. > > Andy > > > On Feb 26, 2018, at 9:23 AM, Andy Balholm > wrote: > > > > There is no guarantee that

Re: [go-nuts] Is there some kind of memory write protection mechanism?

Oops. I left out a couple words. I meant “does not keep”. Andy > On Feb 26, 2018, at 9:23 AM, Andy Balholm wrote: > > There is no guarantee that the unsafe package even exists in every > implementation of Go. For example, I really doubt that GopherJS has it. But > that keep GopherJS from bein

Re: [go-nuts] Is there some kind of memory write protection mechanism?

There is no guarantee that the unsafe package even exists in every implementation of Go. For example, I really doubt that GopherJS has it. But that keep GopherJS from being compliant with the Go spec and the Go 1 compatibility guarantee. (I’m not sure whether GopherJS is to the point of full co

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Monday, February 26, 2018 at 11:48:36 AM UTC-5, Jakob Borg wrote: > > On 26 Feb 2018, at 16:38, di...@veryhaha.com wrote: > > > Will the "sync/atomic" package get broken? > This atomic package imports unsafe. > > > If changes to unsafe break sync/atomic it’s up to the Go team to fix > sync/a

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On 26 Feb 2018, at 16:38, d...@veryhaha.com wrote: Will the "sync/atomic" package get broken? This atomic package imports unsafe. If changes to unsafe break sync/atomic it’s up to the Go team to fix sync/atomic before releasing. Much like it’s up to other package author

[go-nuts] Vgo and reproducable builds

Right at the beginning of the first post about vgo it is stated: > Versioning will also let us ensure that a program builds exactly the same way > tomorrow as it does today. Even when there are newer versions of my > dependencies, the go command shouldn't start using them until asked. However

[go-nuts] Re: http client for go-server-timing

Hi Eyal, here’s a code review. Perhaps there’s a simpler name? Something like “timing.Timer” would look better than “clienttiming.Timer”. return fmt.Sprintf("%s %s", req.Method, req.URL.Path) could just be return req.Method + “ “ + req.URL.Path which removes the package fmt dependency. The g

Re: [go-nuts] Is there some kind of memory write protection mechanism?

On Sunday, February 25, 2018 at 11:46:02 PM UTC-5, Rob 'Commander' Pike wrote: > > No. As I said, there are no guarantees. As it says in > https://golang.org/doc/go1compat: > > >- Use of package unsafe. Packages that import unsafe > may depend on interna

[go-nuts] http client for go-server-timing

Hi, Recently mitchellh wrote a really awesome library that provide HTTP middleware for server-timing headers. I saw that and thought it would be really nice to automate those headers for HTTP calls between servers. So I created this library: https

[go-nuts] Re: vgo and handling major versions

gopkg.in already "redirects" different import paths to different branches in your repo. You then use correct module name in go.mod in each branch and it all just works. As for "major version inside import branches" , it seems to be a cornerstone of whole vgo proposal, so I doubt it is up for d

[go-nuts] Golang resumable http upload

Hi! I'd like to implement an upload handler that is resumable in case of connection failure. Does net/http server support this use case? partial uploads and content range? Amazon and Google use their specific protocols. I found the Tusd protocol server implemented in Go, which I read has rec

[go-nuts] Re: vgo and handling major versions

I feel uneasy a bit about tags (since they can come from anywhere/any-branch). But maybe that's just being over pessimistic, about handling/managing major versions. And IDEs should use .mod files to reach for the source code of a definition - which is very helpful at development time. Now there

[go-nuts] Re: vgo and handling major versions

On 26-02-2018, Kaveh Shahbazian wrote: > It would be nice if vgo could handle something like (in .mod files) > `pkg >>1.2.1 branch-name-*` and the `*` part could be a major number and the > `1.2.1` is tag. The `branch-name-*` part is a pattern for branch name. If I understand what you mean, I

[go-nuts] vgo and handling major versions

(IMHO - assuming vgo would care about this) About branches: Having branches for major versions helps greatly. A major version can literally be a whole different package by breaking the API or even introducing a completely new one. However keeping some previous major versions might be de