date:20160820

[go-nuts] Re: golang.org/x/net/ipv4 windows support

2016-08-20 Thread mikioh . mikioh

see golang.org/issues/7175 and golang.org/issues/9252.

-- 
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] Cross compilation to see assembly outputs with go tool compile

2016-08-20 Thread Aram Hăvărneanu

You might also be interested in

GOOS=linux GOARCH=arm go build -gcflags='-S' foo

or

GOOS=linux GOARCH=arm go build -gcflags='-S' -asmflags='-S' foo

-- 
Aram Hăvărneanu

-- 
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] Unary +

2016-08-20 Thread Ian Lance Taylor

On Sat, Aug 20, 2016 at 1:24 PM, Bakul Shah  wrote:
>
> In Go there are two issues:
> The compiler refuses to divide by the constant 0.0 — This operation has a
> well defined meaning but the compiler thinks it knows best (this behavior is
> documented in the spec, which is good, but I don’t see the rationale for
> this behavior).

I agree that it was probably a mistake to make division by constant
zero a compiler error.  But it's not a problem in practice: the only
reason to divide by constant zero is to get a floating point infinity,
and it's clearer and equally efficient to use math.Inf.

> So one has to use a variable to test this … where we run
> into the second problem: -0.0 is treated the same as +0.0:
>
> x := -0.0
> fmt.Println(1.0/x)
>
> This prints +Inf, when it should be printing -Inf. One has to explicitly
> negate x as in
>
> fmt.Println(1.0/-x)

This is by design.  Constants in Go are untyped.  Floating point
constants in particular are not IEEE-754 values.  There are no untyped
negative zeroes or infinities in Go.  There is no floating point
constant overflow--or, rather, any such overflow is a compilation
error.  See https://golang.org/ref/spec#Constants .

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: gophercon 2016 videos

2016-08-20 Thread mhhcbon

yup agreed there are awesome, sadly so few to enjoy ;)

I especially appreciated the one from miss Owen 
(https://www.youtube.com/watch?v=ClPIeuL9HnI), she got it so right, imvho. 

mr Campoy (https://www.youtube.com/watch?v=ynoY2xz-F8s) and its tip to test 
nil struct within a struct method really is interesting.

The one from Rob Pike is refreshing for the simple approach described to 
solve a difficult problem.

Others was good too, don t mistake me!

Hope there ll be more like this.

-- 
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] Unary +

2016-08-20 Thread jimmy frasche

Even if you disagree with Iverson check out
https://en.wikipedia.org/wiki/Iverson_bracket notation. That's good
stuff. It should be the standard notation.


On Sat, Aug 20, 2016 at 1:24 PM, Bakul Shah  wrote:
> Thank goodness for loony ideas, eh? I learned a lot from Iverson’s writings
> and APL and its descendents. It is worth revisiting his writings (just like
> Dikjstra’s) from time to time. Array programming should be much more
> aprpeciated these days when many-core processors are becoming more and cloud
> based services essentially stand up an array of identical servers — and we
> have to use clumsy notation for all this. At any rate mathematics doesn’t
> exactly have a completely logical system of symbols.
>
> Incidentally the only meaningful use of unary +  I’ve seen is in K (another
> array programming language), where it stands for the “transpose” function,
> where the first two axes of an array are swapped.
>
>   (1 2;3 4) // outputs as:
> (1 2
>  3 4)
>   +(1 2;3 4)
> (1 3
>  2 4)
>
>
> Another aside: Go’s treatment of - for constants is a bit weird. I’ll
> explain with an example from Gambit Scheme, which has the correct behavior:
>
>> (/ 1.0 0.0)
> +inf.0
>> (/ 1.0 -0.0)
> -inf.0
>
>
> As you can see -0.0 does have a meaning different from +0.0.
>
> In Go there are two issues:
> The compiler refuses to divide by the constant 0.0 — This operation has a
> well defined meaning but the compiler thinks it knows best (this behavior is
> documented in the spec, which is good, but I don’t see the rationale for
> this behavior). So one has to use a variable to test this … where we run
> into the second problem: -0.0 is treated the same as +0.0:
>
> x := -0.0
> fmt.Println(1.0/x)
>
>
> This prints +Inf, when it should be printing -Inf. One has to explicitly
> negate x as in
>
> fmt.Println(1.0/-x)
>
>
> Aside #3: Lucio, knowledge of K and its friendier version Q (used in KDB+)
> can be very rewarding! They are used in quantitative finance (along with
> python, matlab, ocaml etc). Though the number of available jobs are perhaps
> small (also because one APL/J/K/Q programmer can cause a lot of havoc in
> just one line of code!)
>
> On Aug 20, 2016, at 5:28 AM, Michael Jones  wrote:
>
> I took Thomas’s “loony-land” comment as jest.
>
> Presumably we all study the Turing Award lectures, each being the computer
> science community’s way of passing a life’s celebrated contributions to the
> future. In Dr. Iverson’s Turing Award lecture, “Notation as a Tool of
> Thought,” he explores the link between expression of ideas and the power to
> create and advance ideas. Essentially, that “language shapes thought,” one
> of the beliefs I hold. His use of minus and negative there are not the only
> “loony” (perhaps meaning “other than ordinary”) ideas in what remains to
> this day an intellectual treasure.
>
> I have Iverson’s high-school textbook which uses the notation. You see the
> notation it as APL, but in fact it was created as a way to describe a
> computer architecture (the IBM 360 then in development) in a formalism that
> allowed proofs of operation and implementation. I studied those books too.
> It is not so uncommon that an at first bewildering notation can come to feel
> a comfortable home. This is true of music, mathematics, emacs, and much
> more. Rob Pike’s Ivy is APL themed if you want to explore that. The latest
> descendent of APL is “J,” itself a descendent of “Dictionary APL” which was
> Iverson’s effort to use ordinary notation to lower the initial threshold for
> new programmers.
>
> Michael
>
> From: Lucio 
> Date: Friday, August 19, 2016 at 10:23 PM
> To: golang-nuts 
> Cc: Michael Jones ,
> , 
> Subject: Re: [go-nuts] Unary +
>
>
>
>
> On Saturday, 20 August 2016 02:29:17 UTC+2, Thomas Bushnell, BSG wrote:
>
> With all due respected to the illustrious Dr. Iverson, he was in loony-land
> with his two versions of minus.
>
>
>
> I take exception to the "loony-land" qualification of Dr Iverson's raised
> minus. I think it was immensely appropriate and sadly forgotten that APL
> introduced the brilliant idea of discarding operator precedence in favour of
> making functions themselves operators with NO associated precedence. The use
> of a raised minus to eliminate confusion was a sensible one, one Michael
> Jones further justifies in its use in teaching Algebra (I still smart when I
> remember my confusion in Algebra classes after the teacher dropped all minus
> and plus signs and the parentheses she'd used until then!).
>
> Even sadder, I find the disappearance of RPN from hand-held calculators, for
> which I hold HP almost entirely responsible.
>
> That APL is still available in some form or other I find emotionally,but
> sadly not economically, rewarding. My short liaison with the language has
> given me a

Re: [go-nuts] Unary +

2016-08-20 Thread Bakul Shah

Thank goodness for loony ideas, eh? I learned a lot from Iverson’s writings and 
APL and its descendents. It is worth revisiting his writings (just like 
Dikjstra’s) from time to time. Array programming should be much more 
aprpeciated these days when many-core processors are becoming more and cloud 
based services essentially stand up an array of identical servers — and we have 
to use clumsy notation for all this. At any rate mathematics doesn’t exactly 
have a completely logical system of symbols.

Incidentally the only meaningful use of unary +  I’ve seen is in K (another 
array programming language), where it stands for the “transpose” function, 
where the first two axes of an array are swapped.

  (1 2;3 4) // outputs as:
(1 2
 3 4)
  +(1 2;3 4)
(1 3
 2 4)

Another aside: Go’s treatment of - for constants is a bit weird. I’ll explain 
with an example from Gambit Scheme, which has the correct behavior:

> (/ 1.0 0.0)
+inf.0
> (/ 1.0 -0.0)
-inf.0

As you can see -0.0 does have a meaning different from +0.0.

In Go there are two issues:
The compiler refuses to divide by the constant 0.0 — This operation has a well 
defined meaning but the compiler thinks it knows best (this behavior is 
documented in the spec, which is good, but I don’t see the rationale for this 
behavior). So one has to use a variable to test this … where we run into the 
second problem: -0.0 is treated the same as +0.0:

x := -0.0
fmt.Println(1.0/x)

This prints +Inf, when it should be printing -Inf. One has to explicitly negate 
x as in

fmt.Println(1.0/-x)

Aside #3: Lucio, knowledge of K and its friendier version Q (used in KDB+) can 
be very rewarding! They are used in quantitative finance (along with python, 
matlab, ocaml etc). Though the number of available jobs are perhaps small (also 
because one APL/J/K/Q programmer can cause a lot of havoc in just one line of 
code!)

> On Aug 20, 2016, at 5:28 AM, Michael Jones  wrote:
> 
> I took Thomas’s “loony-land” comment as jest. 
>  
> Presumably we all study the Turing Award lectures, each being the computer 
> science community’s way of passing a life’s celebrated contributions to the 
> future. In Dr. Iverson’s Turing Award lecture, “Notation as a Tool of Thought 
> ,” he 
> explores the link between expression of ideas and the power to create and 
> advance ideas. Essentially, that “language shapes thought,” one of the 
> beliefs I hold. His use of minus and negative there are not the only “loony” 
> (perhaps meaning “other than ordinary”) ideas in what remains to this day an 
> intellectual treasure.
>  
> I have Iverson’s high-school textbook which uses the notation. You see the 
> notation it as APL, but in fact it was created as a way to describe a 
> computer architecture (the IBM 360 then in development) in a formalism that 
> allowed proofs of operation and implementation. I studied those books too. It 
> is not so uncommon that an at first bewildering notation can come to feel a 
> comfortable home. This is true of music, mathematics, emacs, and much more. 
> Rob Pike’s Ivy is APL themed if you want to explore that. The latest 
> descendent of APL is “J,” itself a descendent of “Dictionary APL” which was 
> Iverson’s effort to use ordinary notation to lower the initial threshold for 
> new programmers.
>  
> Michael
>  
> From: Lucio 
> Date: Friday, August 19, 2016 at 10:23 PM
> To: golang-nuts 
> Cc: Michael Jones , , 
> 
> Subject: Re: [go-nuts] Unary +
>  
>> 
>> 
>> On Saturday, 20 August 2016 02:29:17 UTC+2, Thomas Bushnell, BSG wrote:
>>> With all due respected to the illustrious Dr. Iverson, he was in loony-land 
>>> with his two versions of minus.
>>>  
>>>  
>> I take exception to the "loony-land" qualification of Dr Iverson's raised 
>> minus. I think it was immensely appropriate and sadly forgotten that APL 
>> introduced the brilliant idea of discarding operator precedence in favour of 
>> making functions themselves operators with NO associated precedence. The use 
>> of a raised minus to eliminate confusion was a sensible one, one Michael 
>> Jones further justifies in its use in teaching Algebra (I still smart when I 
>> remember my confusion in Algebra classes after the teacher dropped all minus 
>> and plus signs and the parentheses she'd used until then!).
>>  
>> Even sadder, I find the disappearance of RPN from hand-held calculators, for 
>> which I hold HP almost entirely responsible.
>>  
>> That APL is still available in some form or other I find emotionally,but 
>> sadly not economically, rewarding. My short liaison with the language has 
>> given me a perspective I still believe helped shape all of my computing 
>> experience since those late 1970 years.
>>  
>> Lucio.
> 
> 
> -- 
> You received this message because

Re: [go-nuts] Weired or not?

2016-08-20 Thread xiiophen

This is 

*The method set of any other type T consists of all methods 
 declared with receiver 
type T. *

[me] (but not *T) 

 
and

*The method set of the corresponding pointer type 
 *T is the set of all methods 
declared with receiver *T or T *


plus embedding

so another way/example

package main

type S1 struct{}

func (*S1) f() {}
func (S1) g()  {}

type S2 struct{ S1 }

func main() {
// var _ = (S2).f // not ok!
var _ = (*S2).f // ok!

var _ = (*S2).g // ok!
var _ = (S2).g  // ok!
}


and S1 behaves the same (obviously)

-- 
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: Complete SSL certificate workflow

2016-08-20 Thread Josh V

Thanks! I wish I would have found that repo a week ago. It would have saved 
me a lot of stress :)

On Saturday, August 20, 2016 at 1:11:57 PM UTC-6, Manlio Perillo wrote:
>
> You can take a look at
> https://github.com/perillo/tls-cert
>
>
> Manlio
>
> Il giorno mercoledì 17 agosto 2016 18:58:18 UTC+2, Mi-e Foame ha scritto:
>>
>> Sorry, I should have mentioned that the primary goal here is to generate 
>> certificates for the specific purpose of client authentication.
>>
>> On Wednesday, August 17, 2016 at 10:01:01 AM UTC-6, Josh V wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to come up with an example of how to create SSL certificates 
>>> and keys from start to finish (including CertificateRequests) all using Go. 
>>> I'll go ahead and get the obligatory "I'm pretty new to SSL" disclaimer out 
>>> of the way... I've played with 
>>> https://golang.org/src/crypto/tls/generate_cert.go quite a bit trying 
>>> to understand what all needs to happen, but that program doesn't cover some 
>>> cases I'd like to get working. Here's what I would like to build:
>>>
>>>- Server piece
>>>   - Generates a new private
>>>   - Generates a new x509.Certificate (with IsCA: true) using the 
>>>   new private key
>>>   - Write both the cert and key to disk
>>>   - Spin up an HTTP server to accept CSR->Certificate requests
>>>   - Spin up an HTTPS server to accept requests from clients to test 
>>>   their newly generated certificates
>>>- Client piece
>>>   - Generates a new private key
>>>   - Creates a x509.CertificateRequest
>>>   - POSTs the CertificateRequest off to the server's HTTP piece
>>>   - Receives a response containing the client's fresh Certificate
>>>   - Writes both the cert and the key to disk
>>>   - Successfully connects to the server's HTTPS piece using the 
>>>   newly generated certificate
>>>
>>> I've been working on a project that basically does (or tries to do) all 
>>> of this, and things were looking promising for a while. I have (I guess 
>>> what you'd call) a "root CA" cert/key that are used to create new client 
>>> certificates from CSRs. The resulting client certificate, client key, and 
>>> CA certificate connect to my server piece just fine when I use curl. But 
>>> when I try to use those same files in the Go client, I get an "x509: 
>>> certificate signed by unknown authority" error. I've tried as many 
>>> variations on the tls.Config.ClientCAs and RootCAs as I can think of. 
>>> Nothing seems to be just right, so I'm obviously missing something.
>>>
>>> I've tried to whittle my project down to the basic concepts described 
>>> above, which can be found at 
>>> https://gist.github.com/codekoala/c793f020c27bded785fb39f0f2594ee2 ... 
>>> I apologize in advance--it is horrendous code with lots of copy pasta and 
>>> unhandled error cases. I just need to get this out there. If anyone can 
>>> muster up the courage to take a peek at that gist and offer suggestions for 
>>> how to achieve what I've described, please do.
>>>
>>> I realize most people will immediately suggest "just use openssl on the 
>>> command line" to get past these hurdles. I could certainly do that, but I'd 
>>> prefer to keep it all in the standard library, if at all possible. Also, 
>>> from my research, it seems like I should be making a root CA and then an 
>>> intermediate CA that is used to process the actual CSRs and such. If anyone 
>>> can offer insight into the correct way to do that with Go, I'm all eyes.
>>>
>>> Thanks!
>>>
>>> - Josh
>>>
>>

-- 
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: Complete SSL certificate workflow

2016-08-20 Thread Manlio Perillo

You can take a look at
https://github.com/perillo/tls-cert


Manlio

Il giorno mercoledì 17 agosto 2016 18:58:18 UTC+2, Mi-e Foame ha scritto:
>
> Sorry, I should have mentioned that the primary goal here is to generate 
> certificates for the specific purpose of client authentication.
>
> On Wednesday, August 17, 2016 at 10:01:01 AM UTC-6, Josh V wrote:
>>
>> Hi all,
>>
>> I'm trying to come up with an example of how to create SSL certificates 
>> and keys from start to finish (including CertificateRequests) all using Go. 
>> I'll go ahead and get the obligatory "I'm pretty new to SSL" disclaimer out 
>> of the way... I've played with 
>> https://golang.org/src/crypto/tls/generate_cert.go quite a bit trying to 
>> understand what all needs to happen, but that program doesn't cover some 
>> cases I'd like to get working. Here's what I would like to build:
>>
>>- Server piece
>>   - Generates a new private
>>   - Generates a new x509.Certificate (with IsCA: true) using the new 
>>   private key
>>   - Write both the cert and key to disk
>>   - Spin up an HTTP server to accept CSR->Certificate requests
>>   - Spin up an HTTPS server to accept requests from clients to test 
>>   their newly generated certificates
>>- Client piece
>>   - Generates a new private key
>>   - Creates a x509.CertificateRequest
>>   - POSTs the CertificateRequest off to the server's HTTP piece
>>   - Receives a response containing the client's fresh Certificate
>>   - Writes both the cert and the key to disk
>>   - Successfully connects to the server's HTTPS piece using the 
>>   newly generated certificate
>>
>> I've been working on a project that basically does (or tries to do) all 
>> of this, and things were looking promising for a while. I have (I guess 
>> what you'd call) a "root CA" cert/key that are used to create new client 
>> certificates from CSRs. The resulting client certificate, client key, and 
>> CA certificate connect to my server piece just fine when I use curl. But 
>> when I try to use those same files in the Go client, I get an "x509: 
>> certificate signed by unknown authority" error. I've tried as many 
>> variations on the tls.Config.ClientCAs and RootCAs as I can think of. 
>> Nothing seems to be just right, so I'm obviously missing something.
>>
>> I've tried to whittle my project down to the basic concepts described 
>> above, which can be found at 
>> https://gist.github.com/codekoala/c793f020c27bded785fb39f0f2594ee2 ... I 
>> apologize in advance--it is horrendous code with lots of copy pasta and 
>> unhandled error cases. I just need to get this out there. If anyone can 
>> muster up the courage to take a peek at that gist and offer suggestions for 
>> how to achieve what I've described, please do.
>>
>> I realize most people will immediately suggest "just use openssl on the 
>> command line" to get past these hurdles. I could certainly do that, but I'd 
>> prefer to keep it all in the standard library, if at all possible. Also, 
>> from my research, it seems like I should be making a root CA and then an 
>> intermediate CA that is used to process the actual CSRs and such. If anyone 
>> can offer insight into the correct way to do that with Go, I'm all eyes.
>>
>> Thanks!
>>
>> - Josh
>>
>

-- 
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: Complete SSL certificate workflow

2016-08-20 Thread Josh V

I ended up figuring out what I needed to do. Here are some things that I 
did differently when it started working:

   - I created a self-signed root CA. This is possible with 
   generate_cert.go with one minor modification: the KeyUsage must include 
   x509.KeyUsageCertSign.
   - I created an intermediate CA. The x509.Certificate{} stuff was pretty 
   much the same as it was for the root CA. The main difference when creating 
   the intermediate CA certificate is that the x509.CreateCertificate call 
   looks more like x509.CreateCertificate(rand.Reader, , 
   caCert, , caKey) so the certificate will be 
   signed by the root CA instead of being another self-signed certificate.
   - I created a server certificate using the intermediate CA, using a 
   x509.CreateCertificate call similar to the one used to create the 
   intermediate CA: x509.CreateCertificate(rand.Reader, serverTemplate, 
   interCACert, serverTemplate.PublicKey, interCAKey). The x509.Certificate 
   looked like this:
   x509.Certificate{
 SerialNumber: big.NewInt(1),
 Subject: {CommonName: "server.site.local"},
 NotBefore: notBefore,
 NotAfter: notAfter,
 KeyUsage: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
 ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageServerAuth},
 IPAddresses: []net.IP{net.ParseIP("127.0.0.1")},
   }
   - I created a client certificate very similarly to how the server cert 
   was created: x509.CreateCertificate(rand.Reader, clientTemplate, 
   interCACert, clientTemplate.PublicKey, interCAKey). The x509.Certificate 
   looked like this:
   x509.Certificate{
 SerialNumber: big.NewInt(1),
 Subject: {CommonName: "client.site.local"},
 NotBefore: notBefore,
 NotAfter: notAfter,
 KeyUsage: x509.KeyUsageKeyEncipherment | x509.KeyUsageDigitalSignature,
 ExtKeyUsage: []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth},
   }
   - When I created the server, the TLS config had a x509.CertPool 
   containing the intermediate CA certificate as the ClientCAs
   - When I created the client, the TLS config had a x509.CertPool 
   containing the intermediate CA certificate as the RootCAs

I did end up using x509.CertificateRequests to generate the server and 
client certificates. They aren't nearly as complicated as I tried to make 
them at first. Basically, I just used the x509.CertificateRequest's 
PublicKey and Subject to set those attributes when creating the 
x509.Certificate. Done and done.


I hope that helps anyone who stumbles upon this thread having similar 
problems.


- Josh

On Wednesday, August 17, 2016 at 10:01:01 AM UTC-6, Josh V wrote:
>
> Hi all,
>
> I'm trying to come up with an example of how to create SSL certificates 
> and keys from start to finish (including CertificateRequests) all using Go. 
> I'll go ahead and get the obligatory "I'm pretty new to SSL" disclaimer out 
> of the way... I've played with 
> https://golang.org/src/crypto/tls/generate_cert.go quite a bit trying to 
> understand what all needs to happen, but that program doesn't cover some 
> cases I'd like to get working. Here's what I would like to build:
>
>- Server piece
>   - Generates a new private
>   - Generates a new x509.Certificate (with IsCA: true) using the new 
>   private key
>   - Write both the cert and key to disk
>   - Spin up an HTTP server to accept CSR->Certificate requests
>   - Spin up an HTTPS server to accept requests from clients to test 
>   their newly generated certificates
>- Client piece
>   - Generates a new private key
>   - Creates a x509.CertificateRequest
>   - POSTs the CertificateRequest off to the server's HTTP piece
>   - Receives a response containing the client's fresh Certificate
>   - Writes both the cert and the key to disk
>   - Successfully connects to the server's HTTPS piece using the newly 
>   generated certificate
>
> I've been working on a project that basically does (or tries to do) all of 
> this, and things were looking promising for a while. I have (I guess what 
> you'd call) a "root CA" cert/key that are used to create new client 
> certificates from CSRs. The resulting client certificate, client key, and 
> CA certificate connect to my server piece just fine when I use curl. But 
> when I try to use those same files in the Go client, I get an "x509: 
> certificate signed by unknown authority" error. I've tried as many 
> variations on the tls.Config.ClientCAs and RootCAs as I can think of. 
> Nothing seems to be just right, so I'm obviously missing something.
>
> I've tried to whittle my project down to the basic concepts described 
> above, which can be found at 
> https://gist.github.com/codekoala/c793f020c27bded785fb39f0f2594ee2 ... I 
> apologize in advance--it is horrendous code with lots of copy pasta and 
> unhandled error cases. I just need to get this out there. If anyone can 
> muster up the courage to take a peek at that gist and offer

Re: [go-nuts] Understanding go routine heap

2016-08-20 Thread Marvin Renich

* Konstantin Shaposhnikov  [160820 06:34]:
> The code might be race free for the current Go implementation but I don't 
> think this behaviour is documented. 
> 
> https://golang.org/ref/mem doesn't mention sync.WaitGroup at all. So 
> wg.Done() doesn't necessarily happen before wg.Wait() returns and the 
> effect of writing to "result" could be not visible after wg.Wait().

I don't believe that https://golang.org/ref/mem should necessarily be
required to mention every library routine that guarantees a
happens-before relationship.  It should document the lowest-level
language features, and then the documentation for the library routines
should make a claim that their implementations guarantee such a
relationship.

For sync.WaitGroup, the documentation says "A WaitGroup waits for a
collection of goroutines to finish."  For func (*WaitGroup) Wait, the
documentation says "Wait blocks until the WaitGroup counter is zero."
Perhaps the documentation should explicitly mention the Go Memory Model
and state that it is implemented in such a way that a happens-before
relationship exists, but what would be the purpose of WaitGroup if it
didn't guarantee such a relationship?

I believe the happens-before relationship is implied by the current
documentation and the intended use-case for WaitGroup, even if it is not
explicitly stated.

I agree with others in this thread who have stated that there is no race
condition.  I disagree with the implication that WaitGroup, as
documented, could be implemented differently in such a way as to both
conform to the Go 1 compatibility promise and fail to provide an
appropriate happens-before relationship.

...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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] golang.org/x/net/ipv4 windows support

2016-08-20 Thread Matt Harden

The relevant socket option seems to be supported in Windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/hh285668(v=vs.85).aspx

On Thu, Aug 18, 2016 at 8:33 AM  wrote:

> Does anyone know what it would take to implement the windows
> ControlMessage functions for the golang.org/x/net/ipv4 package? I am
> using the ipv4 package to specify the outgoing interface index of UDP
> requests. The following example works correctly on linux but fails with not
> supported by windows (https://play.golang.org/p/n8Q9xPxINn):
>
>
> l := ipv4.NewPacketConn(conn)
> if err = l.SetControlMessage(ipv4.FlagInterface, true); err != nil {
> log.Printf("Unable to set control message %s", err)
> } else {
> log.Printf("set ipv4.FlagInterface success")
> }
>
> 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.
> 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.

Re: [go-nuts] Define method on scope-local type

2016-08-20 Thread 'Axel Wagner' via golang-nuts

You can, of course, create internal packages if you want to, but I'd see
that as completely unnecessary. You can just create an unexported type just
as well. internal packages should be used sparsely.

On Sat, Aug 20, 2016 at 11:34 AM, Paul Jolly  wrote:

> Does it really make sense to create an internal package just to define a
>> single small, one-off type?
>>
>
> It does "feel" like an overkill, yes. But it's one means of solving the
> problem *today*.
>
> Just to be clear; in offering this as a solution, I'm not saying that I'm
> 100% happy with the current state of affairs from a practical or style
> perspective, but rather I understand that changing the status quo does have
> (not inconsiderable) implications.
>
>
>> Also, I don't imagine that any of the optimizations would need to be
>> reconsidered; the scope is strictly a subset of the scope at which the
>> optimizations operated before, so there shouldn't be any *new* optimizations
>> that need to be made here.
>>
>
> I'm no expert on this question of optimisations, but I would guess
> inlining is one area that would need some attention (if it's even
> possible).
>
> --
> 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.
>

-- 
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] Unary +

2016-08-20 Thread Michael Jones

Leadings zeroes signal the use of base 8. Have a look at this “base 10” 
calculator.

 

https://play.golang.org/p/L0whPekuvG

 

There was debate about this in early Go days. It is consistent with historical 
usage (C, and earlier, in Donald Knuth’s Art of Computer Programming.) Good 
summary at Wikipedia (https://en.wikipedia.org/wiki/Octal#In_computers) and in 
this 2009 Go decision (https://github.com/golang/go/issues/151).

 

 

From:  on behalf of Val 
Date: Friday, August 19, 2016 at 9:40 PM
To: golang-nuts 
Cc: 
Subject: Re: [go-nuts] Unary +

 

Hello Ian
Leading zeroes do affect the value : https://play.golang.org/p/h0iE_8_yYK
I personally regard this as a gotcha, and this feeling gets stronger when an 
experienced gopher overlooks it. I put an entry in my go-traps list.
Cheers
Val

On Saturday, August 20, 2016 at 2:55:44 AM UTC+2, Ian Lance Taylor wrote:


The same is true of leading zeroes, which also do not affect the value 
of the expression. 

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.

-- 
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] Remove vs Delete

2016-08-20 Thread Dave Cheney

Additionally in unix, where the name comes from, a file may have many names 
(many hard links to a directory entry) so remove in this case is removing a 
directory entry. Separately, when the link count of a file drops to zero, the 
file is now inaccessible as you cannot link to something that does not have a 
name. You could considered that deleted.

-- 
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] Understanding go routine heap

2016-08-20 Thread Konstantin Shaposhnikov

The code might be race free for the current Go implementation but I don't 
think this behaviour is documented. 

https://golang.org/ref/mem doesn't mention sync.WaitGroup at all. So 
wg.Done() doesn't necessarily happen before wg.Wait() returns and the 
effect of writing to "result" could be not visible after wg.Wait().

On Saturday, 20 August 2016 07:43:52 UTC+1, Jan Mercl wrote:
>
> On Sat, Aug 20, 2016 at 8:29 AM Yulrizka  
> wrote:
>
> > He argues that this is heap race condition. 
>
> I don't know what is a heap race condition but the code is race free.
>
> -- 
>
> -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.

Re: [go-nuts] Understanding go routine heap

2016-08-20 Thread Dave Cheney

I haven't run the code under the race detector (hint, do this and you'll have 
the official answer) but I don't believe wg.Wait creates a happens before event 
that ensures the assignment to result will be visible to other goroutine. 

-- 
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] Define method on scope-local type

2016-08-20 Thread Paul Jolly

>
> Does it really make sense to create an internal package just to define a
> single small, one-off type?
>

It does "feel" like an overkill, yes. But it's one means of solving the
problem *today*.

Just to be clear; in offering this as a solution, I'm not saying that I'm
100% happy with the current state of affairs from a practical or style
perspective, but rather I understand that changing the status quo does have
(not inconsiderable) implications.


> Also, I don't imagine that any of the optimizations would need to be
> reconsidered; the scope is strictly a subset of the scope at which the
> optimizations operated before, so there shouldn't be any *new* optimizations
> that need to be made here.
>

I'm no expert on this question of optimisations, but I would guess inlining
is one area that would need some attention (if it's even possible).

-- 
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] Understanding go routine heap

2016-08-20 Thread Jan Mercl

On Sat, Aug 20, 2016 at 8:29 AM Yulrizka  wrote:

> He argues that this is heap race condition.

I don't know what is a heap race condition but the code is race free.

-- 

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

[go-nuts] Understanding go routine heap

2016-08-20 Thread Yulrizka

Dear gophers

I have discussion with my colleague about this code


func process() *foo {
var result *foo

var wg sync.WaitGroup
wg.Add(1)
go func() {
defer wg.Done()
result = {1}
}()

wg.Wait()

return result
}

He argues that this is heap race condition. 
the result variable which lives on the heap of the go routine is not 
guaranteed to be synced to the result on the process func's thread.
The better approach would be using a channel instead. I may agree with him 
that probably using channel is better.
But I would like to understand the reasoning behind that.

I thought that `wg.Wait()` guaranteed that the process func's thread wait 
until go func is finsihed and sync everything so that the result variable 
is safe to return.

Probably I'm missing some knowledge about how go routine work.

1. Does the process func thread has separate heap than the go func? If so 
how does is sync?
2. From I read so far, when go routine needed a bigger stack, it allocates 
memory from the heap. So what happened for object that is allocated inside 
of the go routine once the go routine returns?

I there article of source that go into details about this I would love to 
read it :)

Warm regards,

-- 
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: golang.org/x/net/ipv4 windows support

Re: [go-nuts] Cross compilation to see assembly outputs with go tool compile

Re: [go-nuts] Unary +

[go-nuts] Re: gophercon 2016 videos

Re: [go-nuts] Unary +

Re: [go-nuts] Unary +

Re: [go-nuts] Weired or not?

[go-nuts] Re: Complete SSL certificate workflow

[go-nuts] Re: Complete SSL certificate workflow

[go-nuts] Re: Complete SSL certificate workflow

Re: [go-nuts] Understanding go routine heap

Re: [go-nuts] golang.org/x/net/ipv4 windows support

Re: [go-nuts] Define method on scope-local type

Re: [go-nuts] Unary +

Re: [go-nuts] Remove vs Delete

Re: [go-nuts] Understanding go routine heap

Re: [go-nuts] Understanding go routine heap

Re: [go-nuts] Define method on scope-local type

Re: [go-nuts] Understanding go routine heap

[go-nuts] Understanding go routine heap

20 matches

Site Navigation

Mail list logo

Footer information