[go-nuts] NOSPLIT on Go assembler defined functions

Hi, 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 which describes the same problem and proposes removing the symbol in

[go-nuts] Re: math integer sizes

Thanks! That is very helpful. On Saturday, February 24, 2018 at 4:52:38 AM UTC-8, Stefan Nilsson wrote: > > I don't know why it's not part of the standard library, but here is a > piece of code that does the job. (It's written in a slightly roundabout way > to make sure that the constants are

Re: [go-nuts] How can I fetch the default locale (server locale not from the request) in Golang

Just an update on the same. Even the library from "Jibber-Jabber" seems to be returning only empty string values. Forced to set this as an ENVIRONMENT_VARIABLE for the time being and moving on. Cheers Anish On Sat, Feb 17, 2018 at 8:05 PM, Anish P wrote: >

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

Digg: If (thought experiment) Go had "const" for variables meaning "you can only set this once"... var x const int = 32 ...and you tried to use unsafe to get the address of x and remove its const-ness and then assign through it the value to x, what do you think would and should happen? a.

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

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 internal properties of the Go implementation. We reserve the right to make changes to the

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

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. On Monday, 26 February 2018 14:02:13 UTC+11, Caleb Spare wrote: > > On a hunch, I profiled a benchmark which just calls time.Now in a loop. >

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

On Sunday, February 25, 2018 at 7:38:22 PM UTC-5, Rob 'Commander' Pike wrote: > > The main rule about unsafe is that your program might work or might not. > There are no guarantees either way. That's why it's called 'unsafe' and why > you shouldn't use it. Your program that 'works' today

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

The main rule about unsafe is that your program might work or might not. There are no guarantees either way. That's why it's called 'unsafe' and why you shouldn't use it. Your program that 'works' today could break tomorrow. -rob On Mon, Feb 26, 2018 at 4:43 AM, Marvin Renich

[go-nuts] Re: New to Go; Saying Hello !

> > I have now embarked on a mission to create an online game, using Go for > the server. What kind of online? Making a server program to run on one computer in a private network is different than a scaling Internet game on one of the cloud platforms. In either case the microservice

Re: [go-nuts] go build -o option not creating a standalone executable, pls help

Thanks alot, Aram. That was it. I missed the cross-compiling part. Regards Raju On Sunday, February 25, 2018 at 2:59:36 PM UTC-8, Aram Hăvărneanu wrote: > > I can guess that you are building a mac binary and then try to run it on > Linux. > > You need to cross-compile your binary for

Re: [go-nuts] go build -o option not creating a standalone executable, pls help

I can guess that you are building a mac binary and then try to run it on Linux. You need to cross-compile your binary for linux/amd64: GOOS=linux GOARCH=amd64 go build foo. -- Aram Hăvărneanu -- You received this message because you are subscribed to the Google Groups "golang-nuts"

[go-nuts] go build -o option not creating a standalone executable, pls help

Hi, I tried two different ways for creating a go binary and then executing that binary inside a Linux docker container. One option is working but the second way gives errors. I am trying to understand the difference between the two ways of creating the binary. Thanks in advance for the help.

Re: [go-nuts] Appreciating Go

> That's why I've used *time.Time, not time.Time - if you try to use it when > t.Err is set you'll get panic because of nil value. > > > Runtime checks doesn't count :) Compiler still allowed you to use value, when error was set. -- You received this message because you are subscribed to

Re: [go-nuts] Re: Experience report on coming to Go from a C perspective

On Thursday, February 22, 2018 at 3:58:25 PM UTC-6, Devon H. O'Dell wrote: > > Thanks for pointing this out; I wasn't aware of this new syntax. I > think this gets to about halfway of what I'd hope for. That said, I'd > really like to avoid needing to jump through the hoop of indirection >

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

* d...@veryhaha.com [180225 11:37]: > I think I get it. > Because the above program tries to modify the constant (or program) zone, > which is not allowed. > The following program works: But, note that the language spec does not guarantee it to work. The compiler is free to

Re: [go-nuts] Is this a bug?

The point to remember is that each value of a concrete type has exactly that one concrete type, while each value of an interface type has exactly one interface type and one concrete type. It is also important to note that there is a distinction between "assignability" and "type-assertiblity". *

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

On Sunday, February 25, 2018 at 10:01:44 AM UTC-5, Jan Mercl wrote: > > > On Sun, Feb 25, 2018 at 3:20 PM wrote: > > > I think the unsafe rules allow this. > > Yes, but using unsafe provides no guarantees about writable memory. > > > I never expect it will crash, for I

[go-nuts] Re: Go += Package Versioning

And I later found https://godoc.org/golang.org/x/vgo/vendor/cmd/go, which looks like where you'll be developing new material from the old docs. --dave On Sunday, February 25, 2018 at 11:00:54 AM UTC-5, David Collier-Brown wrote: > > I'm following the discussion and using the blog descriptions,

[go-nuts] Re: Go += Package Versioning

I'm following the discussion and using the blog descriptions, but where are the "man pages"? A search at golang.org for vgo only points me to /src/crypto/x509/root_darwin_armx.go (:-)) Seriously, though, I'll happily help develop and/or edit reference material: I was an O'Reilly author in a

Re: [go-nuts] Re: Go += Package Versioning

On 24/02/18 04:05 PM, Maxim Ivanov wrote: I am replying mostly to https://resea rch.swtch.com/vgo-import article. ... IMHO right solution vgo should promote is to apply semver trick described here: https://github.com/dtolnay/semver-trick/blob/master/README.md . In a nutshell it suggests that

Re: [go-nuts] Re: Go += Package Versioning

On Sunday, February 25, 2018 at 1:08:31 AM UTC-5, Sam Whited wrote: > > FYI, there is an active CL for this here: https://golang.org/cl/95578 > Thanks Sam -- I found it, and it's working fine. I'm still curious as to what I'm doing wrong in executing the tests in x/vgo . --- SER -- You

Re: [go-nuts] Appreciating Go

Hi! On Sun, Feb 25, 2018 at 01:51:08AM -0800, Maxim Ivanov wrote: > > type Time struct { > > Err error > > *time.Time > > } > Problem is that it continues to be product type, nothing really enforces > that you can't use t as a time.Time when

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

On Sun, Feb 25, 2018 at 3:20 PM wrote: > I think the unsafe rules allow this. Yes, but using unsafe provides no guarantees about writable memory. > I never expect it will crash, for I can't get any information about the write protection mechanism. That's not part of the

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

On Sunday, February 25, 2018 at 8:57:53 AM UTC-5, Jan Mercl wrote: > > On Sun, Feb 25, 2018 at 2:29 PM wrote: > > > Why does the following program crash? > > Because the program attempts to write to the R/O text segment. Why is it > doing that? > Yes. I will not do this

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

On Sun, Feb 25, 2018 at 2:29 PM wrote: > Why does the following program crash? Because the program attempts to write to the R/O text segment. Why is it doing that? -- -j -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To

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

Why does the following program crash? package main import "fmt" import "unsafe" import "reflect" func main() { s := "keep" hdr := (*reflect.StringHeader)(unsafe.Pointer()) byteSequence := (*byte)(unsafe.Pointer(hdr.Data)) fmt.Println(*byteSequence) // k *byteSequence = 'j'

Re: [go-nuts] Appreciating Go

On 24 February 2018 at 22:02, Bakul Shah wrote: > r := os.Open(filename) > if isError(r) { return r.(error) } > f := r.(*os.File) // or better: var f *os.File; f = r I don't think the "or better" alternative would be possible. The of r is still `*os.File|error`, not

Re: [go-nuts] Appreciating Go

> Short version to just get a taste: > > type Time struct { > Err error > *time.Time > } > > func now(pass bool) Time { > if !pass { > return Time{Err: errors.New("not now")} >

Re: [go-nuts] Is this a bug?

On Sun, 25 Feb 2018 09:25:42 + Jan Mercl <0xj...@gmail.com> wrote: Jan Mercl writes: > --f4f5e808e63ceebaa7056605faf5 > Content-Type: text/plain; charset="UTF-8" > > On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah wrote: > > > Why not case T2? > > It does match T2 as well.

Re: [go-nuts] Is this a bug?

On Sun, Feb 25, 2018 at 10:23 AM Bakul Shah wrote: > Why not case T2? It does match T2 as well. The order of cases of the type switch maters: https://play.golang.org/p/nb28xHQP7oU -- -j -- You received this message because you are subscribed to the Google Groups

Re: [go-nuts] Is this a bug?

On Sun, 25 Feb 2018 01:01:08 -0800 Dave Cheney wrote: Dave Cheney writes: > --=_Part_12529_340231507.1519549268925 > Content-Type: text/plain; charset="UTF-8" > > Type C conforms to the T1 interface? > > What did you expect? C conforms to both T1 and T2. var x2 T2

Re: [go-nuts] Appreciating Go

Hi! On Sat, Feb 24, 2018 at 02:02:37PM -0800, Bakul Shah wrote: > r := os.Open(filename) > if isError(r) { return r.(error) } > f := r.(*os.File) // or better: var f *os.File; f = r > > Error checking being a common pattern, isError() can be added as a builtin > or trivially in errors pkg.

Re: [go-nuts] Appreciating Go

On Sat, Feb 24, 2018 at 11:04 PM Bakul Shah wrote: > r := os.Open(filename) > if isError(r) { return r.(error) } > f := r.(*os.File) // or better: var f *os.File; f = r > This still does not seem meaningfully different to me, though. * You are writing isError(r), instead of

[go-nuts] Is this a bug?

Type C conforms to the T1 interface? What did you expect? -- 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

[go-nuts] Is this a bug?

https://play.golang.org/p/IMWd3cvgfsU // also replicated below package main import ( "fmt" ) type ( T1 interface{ f1()int; f2()int } T2 interface{ f2()int; f3()int } ) type C int func (c C)f1()int {return 1} func (c C)f2()int {return 2} func (c C)f3()int {return 3}

Re: [go-nuts] Re: Go += Package Versioning

Hi! On Fri, Feb 23, 2018 at 06:23:33PM -0800, Spencer Nelson wrote: > Is it possible for me to have different minor/patch versions for different > modules in one repository? For example, suppose I have this: > > github.com/my/thing/go.mod > github.com/my/thing/blue/go.mod > > And