[go-nuts] better understanding of * and & in go

Can someone answer the question below in the first comment of the ChangeRefValue function? Also can anyone provide better explanations of waht's going on here, or a link that explains? Thanks. playground version: https://play.golang.org/p/8dYdYoL0WI package main import "fmt" func main() {

Re: [go-nuts] net.ListenUDP, ListenTCP & new go routine creation

On Sat, Jun 18, 2016 at 10:17 PM, Manohar Kumar wrote: > > Is it possible that a net.ListenTCP or ListenUDP call can result in new go > routine/OS thread creation ? I guess not all system calls result in a new go > routine (and OS thread if necessary) creation. But

[go-nuts] Re: Gomobile: Large .so/aar file size on Android

If it's still too much a bit can be saved on code size by disabling bounds checking. -- 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

Re: [go-nuts] better understanding of * and & in go

On Mon, 20 Jun 2016 09:28:05 -0700 (PDT) JM wrote: > Can someone answer the question below in the first comment of the > ChangeRefValue function? Also can anyone provide better explanations > of waht's going on here, or a link that explains? Thanks. Could you start with,

Re: [go-nuts] net.ListenUDP, ListenTCP & new go routine creation

On 21 Jun 2016 12:42 a.m., "Manohar Kumar" wrote: > > I am mainly interested in Linux and have to make these calls in a part of the code where new OS thread creation isn't desirable. Please note that changing that aspect of the design itself is not an option for me. If

[go-nuts] net.ListenUDP, ListenTCP & new go routine creation

Hello, Is it possible that a net.ListenTCP or ListenUDP call can result in new go routine/OS thread creation ? I guess not all system calls result in a new go routine (and OS thread if necessary) creation. But ListenTCP & UDP does many things underneath and its not clear if it can lead to new

[go-nuts] Re: Discussion on "Vendoring edge case, critical problem"

But if you vendor, you don't really need type equality do you? Maybe it's a design flaw when types or interfaces with unexported methods from the vendored pkg are visible to the end user of the vendoring pkg. On Sunday, June 19, 2016 at 10:52:34 PM UTC+2, Dave Cheney wrote: > > If you mean

Re: [go-nuts] [ANN] primegen.go: Sieve of Atkin prime number generator

Edit: Corrected, forgot to change the new count routine to 48 from 8... We have proven with the straight translation of Daniel Bernstein's C code to golang that the Sieve of Eratosthenes (SoE) eratspeed runs about the same speed as the Sieve of Atkin (SoA) primespeed for the same range with

Re: [go-nuts] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

>> Keeping a a pointer in a uintptr as a "reference" to something is safe iff it will never be casted back to a pointer. I think this means that the safe case is useless. Storing any reference (read: address) of Go instance is unsafe because after when this operation ends then a stored address

Re: [go-nuts] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

Thank you for re-opening and answering the question. The original reason why I closed it was because after looking it up in the unsafe package documentation (as I was skimming through source-code originally) it states in Section 2, Paragraph 4 (I feel

Re: [go-nuts] better understanding of * and & in go

Here's a short video I made. I hope this helps explain it: https://www.youtube.com/watch?v=hMSYabOnA3M -- 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

[go-nuts] Re: A proposal for generic in go

Overhead at runtime will be not very big; 1. Generate each time an instance of specific generic type with arguments 2. Perform generic specific type checks before any kind of an assignements 1. The first overhead can be reduced (eleminated) by the static code generation of specified generic

Re: [go-nuts] net.ListenUDP, ListenTCP & new go routine creation

On Monday, June 20, 2016 at 9:31:08 AM UTC-7, Ian Lance Taylor wrote: > > On Sat, Jun 18, 2016 at 10:17 PM, Manohar Kumar > wrote: > > > > Is it possible that a net.ListenTCP or ListenUDP call can result in new > go > > routine/OS thread creation ? I guess not all

[go-nuts] Result is sometimes different despite using same value when encode by encoding/gob

Hello guys, I'm trying to use encoding/gob package to know how it works. And I wrote below codes. import "encoding/gob" func ToGOB64(data interface{}) (string, error) { b := bytes.Buffer{} e := gob.NewEncoder() err := e.Encode(data) if err != nil { fmt.Println(`failed gob Encode`, err)

[go-nuts] Re: Result is sometimes different despite using same value when encode by encoding/gob

To serialise the keys and values of a map and code would have to iterate over it for k,v := range m { // serialise k and v } But map iteration does not have a guaranteed ordering. This is why the result is not stable. On Tuesday, 21 June 2016 15:44:05 UTC+10, Harry wrote: > > Hello guys,

[go-nuts] Re: A proposal for generic in go

As for me then everything is much more simple if Go language (as the starting point) will introduce a non-reified generics. Non reified generics does not requires a complex runtime support (static code which was generated by the compiler will be enough). Type checking of the type arguments

Re: [go-nuts] Unmarshalling and tags

2016-06-19 12:42 GMT+02:00 'Mihai B' via golang-nuts : > I have a struct that needs to be marshalled/unmarshalled using various > serialization formats(xml, json, name/value). The tags start to represent a > considerable effort[0] so I'm wondering if this is a common

Re: [go-nuts] Is there any overhead to casting a pointer (or uintptr) to and from unsafe.Pointer? Can uintptr be safely used to reference an object?

On Mon, Jun 20, 2016 at 1:08 PM, Ian Lance Taylor wrote: > On Mon, Jun 20, 2016 at 10:39 AM, Jason E. Aten > wrote: > > This does raise an interesting question: how should one detect cycles in > a > > graph of Go objects, in a garbage-collection safe manner?

[go-nuts] golang.org/x/text/transform.Chain is not thread safe

Dear all, the following code panics with: runtime error: slice bounds out of range var testTransform = transform.Chain(norm.NFD, norm.NFC) func main() { for i := 0; i < 200; i++ { go func() { transform.String(testTransform, "nonemptystring") }() } time.Sleep(time.Second) } The reason is

Re: [go-nuts] net.ListenUDP, ListenTCP & new go routine creation

On Mon, Jun 20, 2016 at 8:09 PM, Matt Harden wrote: > OK, wait. You mentioned namespaces. It is definitely not supported in any > way to have different threads or goroutines running in different namespaces > within a single Go process. The Go scheduler can move a goroutine

[go-nuts] Re: Example for using JWT with SermoDigital/jose/jws

Thanks Scott. Even after changing it to RS256 I get the same error. On Monday, June 20, 2016 at 7:14:10 PM UTC-7, macmilla...@gmail.com wrote: > > I get this error 'Error serializing the key. json: error calling > MarshalJSON for type jws.Claims: unexpected end of JSON input' > I believe that I

Re: [go-nuts] Fedora and crypto/elliptic.P224

Yep, that's exactly what I'm saying. https://lists.stg.fedoraproject.org/archives/list/gol...@lists.fedoraproject.org/thread/ZLKQK7BOBVQVZ5B2ACQSXCOAOKLVRSTL/ https://bugzilla.redhat.com/show_bug.cgi?id=1038683 Supposedly patent/legal reasons? On Mon, Jun 20, 2016 at 9:03 PM, Ian Lance Taylor

[go-nuts] Fedora and crypto/elliptic.P224

Should there be a note in the documentation that this has been removed by the Fedora packagers? It would help assure developers that they're not insane when they get a compile error claiming that something that https://golang.org/pkg/crypto/elliptic says should be there, isn't there. -- You

[go-nuts] Re: Example for using JWT with SermoDigital/jose/jws

You're loading in an RSA key but signing with HS512, try changing: signMethod := jws.GetSigningMethod("HS512") to signMethod := jws.GetSigningMethod("RS256") On Monday, June 20, 2016 at 10:14:10 PM UTC-4, macmilla...@gmail.com wrote: > > I get this error 'Error serializing the key. json:

Re: [go-nuts] golang.org/x/text/transform.Chain is not thread safe

On Mon, Jun 20, 2016 at 5:57 PM, Bryan Reynaert wrote: > > the following code panics with: runtime error: slice bounds out of range > > > var testTransform = transform.Chain(norm.NFD, norm.NFC) > > func main() { > for i := 0; i < 200; i++ { > go func() { >

Re: [go-nuts] Fedora and crypto/elliptic.P224

On Mon, Jun 20, 2016 at 6:59 PM, wrote: > > Should there be a note in the documentation that this has been removed by > the Fedora packagers? > > It would help assure developers that they're not insane when they get a > compile error claiming that something that >

Re: [go-nuts] Fedora and crypto/elliptic.P224

If the distribution builders can take it out, what is preventing them from adding their own documentation? On Monday, June 20, 2016 at 9:06:26 PM UTC-7, Joshua Chase wrote: > > Yep, that's exactly what I'm saying. > > >

Re: [go-nuts] Fedora and crypto/elliptic.P224

On Mon, Jun 20, 2016 at 9:18 PM, wrote: > > Nothing is stopping them, but people aren't going to go to the distribution > docs for the Go standard library - they're going to go to the official docs. It is not sustainable for us to provide distro-specific docs for

Re: [go-nuts] A proposal for generic in go

Micky, I'm not sure where you're quoting from but they never said it's never gonna happen. >From the FAQ: "Generics may well be added at some point." and "This remains an open issue". https://golang.org/doc/faq#generics On Mon, Jun 20, 2016 at 4:54 PM Micky wrote: >

[go-nuts] Re: Is there a bug in path.Dir?

Package "filepath" works well, but the "path" package is not recommended ? 在 2016年6月20日星期一 UTC+8下午1:40:55，徐新华写道： > > Package path implements utility routines for manipulating > slash-separated(/) paths. > > So, you should use "path/filepath" > -- You received this message because you are

Re: [go-nuts] [ANN] primegen.go: Sieve of Atkin prime number generator

On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote: Further to the subject of compiler efficiency, the following is the assembler code output with array bounds checking turned off (-B) the the inner tight composite culling loop of FasterEratspeed above (generated with go tool

Re: [go-nuts] [ANN] primegen.go: Sieve of Atkin prime number generator

On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote: Further to the subject of compiler efficiency, the following is the assembler code output with array bounds checking turned off (-B) the the inner tight composite culling loop of FasterEratspeed above (generated with go tool

Re: [go-nuts] net.ListenUDP, ListenTCP & new go routine creation

Nothing about using the network requires new goroutine creation. I wouldn't expect Dial to create new goroutines, except perhaps temporarily during DNS lookup or something. On Mon, Jun 20, 2016 at 6:38 PM Manohar Kumar wrote: > > > On Monday, June 20, 2016 at 9:31:08 AM

Re: [go-nuts] Re: Is there a bug in path.Dir?

On Mon, Jun 20, 2016 at 5:59 PM, <18126523...@163.com> wrote: > Package "filepath" works well, but the "path" package is not recommended ? The path package is for slash-separated packages such as appear in URLs. The path/filepath package is for paths in the file system. Ian > 在 2016年6月20日星期一

Re: [go-nuts] Re: Currying in Go

Thank you, Jesper, that's very interesting. On Sunday, June 19, 2016 at 8:15:13 AM UTC-7, Jesper Louis Andersen wrote: > > > On Sat, Jun 18, 2016 at 5:32 AM, Tyler Compton > wrote: > >> I don't pretend to be proficient in this realm of functional programming, >> but I would

[go-nuts] Re: Discussion on "Vendoring edge case, critical problem"

On Tuesday, 21 June 2016 00:42:54 UTC+10, Chad wrote: > > But if you vendor, you don't really need type equality do you? > That sounds like a lot to give up. > Maybe it's a design flaw when types or interfaces with unexported methods > from the vendored pkg are visible to the end user of