Re: [go-nuts] Convert *C.char to array of strings in Go

[Nitish Saboo]

Hi,
I have this method:

func CallBack(key *C.char, value *C.char, value_len C.size_t){

}

and the *value* parameter in the arguments is containing the given string
'Fp5PpR2roT6uPnte47  image/gif'.
I want to extract only first word from the string.Let me know how can I do
this.

I don't want  to split the string into a slice of individual characters.

Thanks

On Wed, May 1, 2019 at 6:27 AM Justin Israel  wrote:

>
>
> On Wednesday, May 1, 2019 at 7:06:47 AM UTC+12, Nitish Saboo wrote:
>>
>> Apologies.I did this 'strings.Split(C.GoString(*C.char),"").
>> I am getting 'Incompatible types' compilation error.
>>
>
> Are you literally doing this?
> strings.Split(C.GoString(*C.char),"")
>
> Something like this should be working correctly:
>
> someCArr := getSomeCArr()
> chars := strings.Split(C.GoString(someCArr),"")
>
> Is your goal to split the string into a slice of individual characters?
> Because that is what your delim suggests.
>
>
>> Thanks
>>
>>
>> On Wed, May 1, 2019 at 12:30 AM Nitish Saboo  wrote:
>>
>>> Hi,
>>>
>>> I want to convert *C.char to array of strings in Go.
>>> I want to do this because I want the first word from the string.Strings
>>> are getting appended to *C.char and I want the first word of the string.
>>> I am doing it using 'strings.Split(C.GoString(*C.char))[0]', but it is
>>> giving error.
>>> Can someone correct me 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 golan...@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.
>

-- 
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] Convert *C.char to array of strings in Go

[Justin Israel]

On Wednesday, May 1, 2019 at 7:06:47 AM UTC+12, Nitish Saboo wrote:
>
> Apologies.I did this 'strings.Split(C.GoString(*C.char),"").
> I am getting 'Incompatible types' compilation error.
>

Are you literally doing this?
strings.Split(C.GoString(*C.char),"")

Something like this should be working correctly:

someCArr := getSomeCArr()
chars := strings.Split(C.GoString(someCArr),"")

Is your goal to split the string into a slice of individual characters? 
Because that is what your delim suggests.


> Thanks
>
>
> On Wed, May 1, 2019 at 12:30 AM Nitish Saboo  > wrote:
>
>> Hi,
>>
>> I want to convert *C.char to array of strings in Go.
>> I want to do this because I want the first word from the string.Strings 
>> are getting appended to *C.char and I want the first word of the string.
>> I am doing it using 'strings.Split(C.GoString(*C.char))[0]', but it is 
>> giving error.
>> Can someone correct me 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 golan...@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.

[go-nuts] Re: There is definitely a race condition, why it can't be detected by race condition detector?

[keith . randall]

The race detector has many special cases for packages like sync and 
runtime, so it can detect synchronization operations.
I haven't looked, but I wouldn't be surprised if the race detector ignored 
package sync's code bodies and just hard coded the semantics of each 
operation.

On Monday, April 29, 2019 at 8:18:39 PM UTC-7, jacki...@gmail.com wrote:
>
> On line 85 in 
> https://github.com/golang/go/blob/release-branch.go1.12/src/sync/mutex.go , 
> the code " old := m.state " is weired because m.state is read and write 
> by different goroutine.
> Why it can't be detected by race condition detector.
>
>
> I write a function Test with race condition problem. 
> If put it in src/sync/mutex.go, it can't be detected.
> If put it in other package like os.go, it can be detected.
> That's weired, anyone has some idea ?
>
>
> package main
> import(
> "sync"
> "os")
> func main(){
> sync.Test()// race condition will not detect
> os.Test()  // race condition will detect}
>
>
>
> func Test(){
> a := int32(1)
>
> if race.Enabled {
> race.Acquire(unsafe.Pointer(&a))
> }
>
> go func(){
> atomic.CompareAndSwapInt32(&a, 1, 4)
> }()
> _ = a}
>
>

-- 
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] Re: Get fingerprint of ca

[Vasiliy Tolstov]

вт, 30 апр. 2019 г. в 23:30, Marcin Romaszewicz :
>
> Now we're onto the topic of TLS chain of trust. The full answer is 
> complicated.
>
> In your case, I think the answer is Yes.
>
> Say you have RootCA which signs SubCA which signs ServerCert.
>
> When your server serves on the internet, it can present just ServerCert to 
> the clients, and if the clients know (SubCa, RootCA), then the server doesn't 
> need to present them. If the clients only trust (RootCA), then the server 
> would have to present (ServerCA, SubCA) to the clients in order to build the 
> chain of trust. All the certificates involved in a connection must be 
> presented, but where you stop checking the chain is up to you.
>
> Have a look here as starting points.
> https://ericchiang.github.io/post/go-tls/
> https://security.stackexchange.com/questions/130847/how-tls-certificate-chain-is-verified
>
>

Thank you for help. Now i think that i have all needed pieces and next
steps is to write simple code that acts like i need =)

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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] Re: Need help to launch hello.go

[andrey mirtchovski]

I'm sorry that I can't help more. It appears to me that the go builder
was able to create some of the temporary files it needs, but not
others. This is a very strange situation that I have not seen before.
Akin to having a full disk or otherwise exhausting the storage
availability.

I do not know how to diagnose any more of this on windows. Apologies.

On Tue, Apr 30, 2019 at 1:11 PM Avetis Sargsian
 wrote:
>
> Ok there is one file in
> E:\temp\go-build828919622\b001\importcfg.link
> end is empty in
> E:\temp\go-build828919622\b001\exe
>
> this is content of importcfg.link
> packagefile 
> hello=C:\Users\Avetis\AppData\Local\go-build\ae\aecfeab49f117df031d74e0ca3aad783ba25f0524b981cbb74a2db671205fadd-d
> packagefile fmt=C:\Go\pkg\windows_amd64\fmt.a
> packagefile runtime=C:\Go\pkg\windows_amd64\runtime.a
> packagefile errors=C:\Go\pkg\windows_amd64\errors.a
> packagefile internal/fmtsort=C:\Go\pkg\windows_amd64\internal\fmtsort.a
> packagefile io=C:\Go\pkg\windows_amd64\io.a
> packagefile math=C:\Go\pkg\windows_amd64\math.a
> packagefile os=C:\Go\pkg\windows_amd64\os.a
> packagefile reflect=C:\Go\pkg\windows_amd64\reflect.a
> packagefile strconv=C:\Go\pkg\windows_amd64\strconv.a
> packagefile sync=C:\Go\pkg\windows_amd64\sync.a
> packagefile unicode/utf8=C:\Go\pkg\windows_amd64\unicode\utf8.a
> packagefile internal/bytealg=C:\Go\pkg\windows_amd64\internal\bytealg.a
> packagefile internal/cpu=C:\Go\pkg\windows_amd64\internal\cpu.a
> packagefile 
> runtime/internal/atomic=C:\Go\pkg\windows_amd64\runtime\internal\atomic.a
> packagefile 
> runtime/internal/math=C:\Go\pkg\windows_amd64\runtime\internal\math.a
> packagefile 
> runtime/internal/sys=C:\Go\pkg\windows_amd64\runtime\internal\sys.a
> packagefile sort=C:\Go\pkg\windows_amd64\sort.a
> packagefile sync/atomic=C:\Go\pkg\windows_amd64\sync\atomic.a
> packagefile math/bits=C:\Go\pkg\windows_amd64\math\bits.a
> packagefile internal/poll=C:\Go\pkg\windows_amd64\internal\poll.a
> packagefile 
> internal/syscall/windows=C:\Go\pkg\windows_amd64\internal\syscall\windows.a
> packagefile internal/testlog=C:\Go\pkg\windows_amd64\internal\testlog.a
> packagefile syscall=C:\Go\pkg\windows_amd64\syscall.a
> packagefile time=C:\Go\pkg\windows_amd64\time.a
> packagefile unicode/utf16=C:\Go\pkg\windows_amd64\unicode\utf16.a
> packagefile unicode=C:\Go\pkg\windows_amd64\unicode.a
> packagefile internal/race=C:\Go\pkg\windows_amd64\internal\race.a
> packagefile 
> internal/syscall/windows/sysdll=C:\Go\pkg\windows_amd64\internal\syscall\windows\sysdll.a
> packagefile 
> internal/syscall/windows/registry=C:\Go\pkg\windows_amd64\internal\syscall\windows\registry.a
>
> вт, 30 апр. 2019 г. в 18:57, andrey mirtchovski :
>>
>> > PS F:\GoWorckspace\src\hello> go build -work
>> > WORK=E:\temp\go-build828919622
>> > open E:\temp\go-build828919622\b001\exe\a.out.exe: The system cannot find 
>> > the file specified.
>>
>> once you have done this you should be able to cd to
>> E:\temp\go-build828919622 and look around to see if any files have
>> been created, including b001\exe\a.out.exe.

-- 
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] Re: Get fingerprint of ca

[Marcin Romaszewicz]

Now we're onto the topic of TLS chain of trust. The full answer is
complicated.

In your case, I think the answer is Yes.

Say you have RootCA which signs SubCA which signs ServerCert.

When your server serves on the internet, it can present just ServerCert to
the clients, and if the clients know (SubCa, RootCA), then the server
doesn't need to present them. If the clients only trust (RootCA), then the
server would have to present (ServerCA, SubCA) to the clients in order to
build the chain of trust. All the certificates involved in a connection
must be presented, but where you stop checking the chain is up to you.

Have a look here as starting points.
https://ericchiang.github.io/post/go-tls/
https://security.stackexchange.com/questions/130847/how-tls-certificate-chain-is-verified



On Tue, Apr 30, 2019 at 1:12 PM Vasiliy Tolstov  wrote:

> вт, 30 апр. 2019 г. в 23:01, Marcin Romaszewicz :
> >
> > Look at the ""crypto/x509" package, specifically at CertPool. You would
> load your CA public cert and intermediate cert's into a CertPool.
> >
> > Once you have a CertPool, you can use it in tls.Config to configure your
> TLS connections. Given a valid certificate chain, Go will automatically
> validate server TLS certificates. If you want client cert validation, you
> have to enable it (
> https://golang.org/src/crypto/tls/common.go?s=8208:8231#L227)
> >
> > Is that what you were looking for?
> >
>
> Thanks looks fine, but does i need to always have root ca to trust
> intermediate certs? Or if i have custom validation in tls.Config i
> don't need it?
> For example i'm pass root ca fingerprint to service, does it possible
> to trust all intermediates if they issued by root CA that have the
> same fingerprint ?
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>

-- 
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] Re: Get fingerprint of ca

[Vasiliy Tolstov]

вт, 30 апр. 2019 г. в 23:01, Marcin Romaszewicz :
>
> Look at the ""crypto/x509" package, specifically at CertPool. You would load 
> your CA public cert and intermediate cert's into a CertPool.
>
> Once you have a CertPool, you can use it in tls.Config to configure your TLS 
> connections. Given a valid certificate chain, Go will automatically validate 
> server TLS certificates. If you want client cert validation, you have to 
> enable it (https://golang.org/src/crypto/tls/common.go?s=8208:8231#L227)
>
> Is that what you were looking for?
>

Thanks looks fine, but does i need to always have root ca to trust
intermediate certs? Or if i have custom validation in tls.Config i
don't need it?
For example i'm pass root ca fingerprint to service, does it possible
to trust all intermediates if they issued by root CA that have the
same fingerprint ?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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] Re: Get fingerprint of ca

[bucarr]

Apologies. I'm quite new to Go and what you are seeking is probably over my 
head.

On Tuesday, April 30, 2019 at 1:53:13 PM UTC-6, Vasiliy Tolstov wrote:
>
> вт, 30 апр. 2019 г. в 16:23, >: 
> > 
> > 
> > If I'm understanding your question correctly, this Youtube video from 
> the 2018 Gophercon should help: 
> https://www.youtube.com/watch?v=kxKLYDLzuHA 
> > 
>
> Thanks, i'm already saw this. My question about ability to get trust 
> root self signed CA cert, and trust all intermediate cert from it. 
> Also trust all client certs from it intermediates. 
>
> -- 
> Vasiliy Tolstov, 
> e-mail: v.to...@selfip.ru  
>

-- 
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] Re: Get fingerprint of ca

[Marcin Romaszewicz]

Look at the ""crypto/x509" package, specifically at CertPool. You would
load your CA public cert and intermediate cert's into a CertPool.

Once you have a CertPool, you can use it in tls.Config to configure your
TLS connections. Given a valid certificate chain, Go will automatically
validate server TLS certificates. If you want client cert validation, you
have to enable it (
https://golang.org/src/crypto/tls/common.go?s=8208:8231#L227)

Is that what you were looking for?

On Tue, Apr 30, 2019 at 12:53 PM Vasiliy Tolstov 
wrote:

> вт, 30 апр. 2019 г. в 16:23, :
> >
> >
> > If I'm understanding your question correctly, this Youtube video from
> the 2018 Gophercon should help:
> https://www.youtube.com/watch?v=kxKLYDLzuHA
> >
>
> Thanks, i'm already saw this. My question about ability to get trust
> root self signed CA cert, and trust all intermediate cert from it.
> Also trust all client certs from it intermediates.
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> 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] Re: Get fingerprint of ca

[Vasiliy Tolstov]

вт, 30 апр. 2019 г. в 16:23, :
>
>
> If I'm understanding your question correctly, this Youtube video from the 
> 2018 Gophercon should help: https://www.youtube.com/watch?v=kxKLYDLzuHA
>

Thanks, i'm already saw this. My question about ability to get trust
root self signed CA cert, and trust all intermediate cert from it.
Also trust all client certs from it intermediates.

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru

-- 
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: the Dominance of English in Programming Languages

[jucie . andrade]

Here in Brazil we usually code in Brazil's native language: Portuguese. 
Yes, there are some companies that mandate the use of English, albeit the 
additional costs of doing so, but that is very exceptional. The vast 
majority of brazilian software houses use Portuguese everywhere.

The only English words are the programming language keywords and library 
function calls, for obvious reasons. This scheme has the advantage that it 
differentiates code created in house from foreign code.

We pick words from the problem domain. So, if we are coding retail software 
for a chain store, we don't even think about using the word "INVOICE" ( are 
you kidding? ) Our clients don't say "invoice", they say "nota fiscal", so 
we code using the name notaFiscal.

That is not nationalism, it's a practical matter and, generally speaking, 
it works great.

-- 
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] Re: Need help to launch hello.go

[Avetis Sargsian]

Ok there is one file in
E:\temp\go-build828919622\b001\importcfg.link
end is empty in
E:\temp\go-build828919622\b001\exe

this is content of importcfg.link
packagefile
hello=C:\Users\Avetis\AppData\Local\go-build\ae\aecfeab49f117df031d74e0ca3aad783ba25f0524b981cbb74a2db671205fadd-d
packagefile fmt=C:\Go\pkg\windows_amd64\fmt.a
packagefile runtime=C:\Go\pkg\windows_amd64\runtime.a
packagefile errors=C:\Go\pkg\windows_amd64\errors.a
packagefile internal/fmtsort=C:\Go\pkg\windows_amd64\internal\fmtsort.a
packagefile io=C:\Go\pkg\windows_amd64\io.a
packagefile math=C:\Go\pkg\windows_amd64\math.a
packagefile os=C:\Go\pkg\windows_amd64\os.a
packagefile reflect=C:\Go\pkg\windows_amd64\reflect.a
packagefile strconv=C:\Go\pkg\windows_amd64\strconv.a
packagefile sync=C:\Go\pkg\windows_amd64\sync.a
packagefile unicode/utf8=C:\Go\pkg\windows_amd64\unicode\utf8.a
packagefile internal/bytealg=C:\Go\pkg\windows_amd64\internal\bytealg.a
packagefile internal/cpu=C:\Go\pkg\windows_amd64\internal\cpu.a
packagefile
runtime/internal/atomic=C:\Go\pkg\windows_amd64\runtime\internal\atomic.a
packagefile
runtime/internal/math=C:\Go\pkg\windows_amd64\runtime\internal\math.a
packagefile
runtime/internal/sys=C:\Go\pkg\windows_amd64\runtime\internal\sys.a
packagefile sort=C:\Go\pkg\windows_amd64\sort.a
packagefile sync/atomic=C:\Go\pkg\windows_amd64\sync\atomic.a
packagefile math/bits=C:\Go\pkg\windows_amd64\math\bits.a
packagefile internal/poll=C:\Go\pkg\windows_amd64\internal\poll.a
packagefile
internal/syscall/windows=C:\Go\pkg\windows_amd64\internal\syscall\windows.a
packagefile internal/testlog=C:\Go\pkg\windows_amd64\internal\testlog.a
packagefile syscall=C:\Go\pkg\windows_amd64\syscall.a
packagefile time=C:\Go\pkg\windows_amd64\time.a
packagefile unicode/utf16=C:\Go\pkg\windows_amd64\unicode\utf16.a
packagefile unicode=C:\Go\pkg\windows_amd64\unicode.a
packagefile internal/race=C:\Go\pkg\windows_amd64\internal\race.a
packagefile
internal/syscall/windows/sysdll=C:\Go\pkg\windows_amd64\internal\syscall\windows\sysdll.a
packagefile
internal/syscall/windows/registry=C:\Go\pkg\windows_amd64\internal\syscall\windows\registry.a

вт, 30 апр. 2019 г. в 18:57, andrey mirtchovski :

> > PS F:\GoWorckspace\src\hello> go build -work
> > WORK=E:\temp\go-build828919622
> > open E:\temp\go-build828919622\b001\exe\a.out.exe: The system cannot
> find the file specified.
>
> once you have done this you should be able to cd to
> E:\temp\go-build828919622 and look around to see if any files have
> been created, including b001\exe\a.out.exe.
>

-- 
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] Convert *C.char to array of strings in Go

[Nitish Saboo]

Apologies.I did this 'strings.Split(C.GoString(*C.char),"").
I am getting 'Incompatible types' compilation error.

Thanks


On Wed, May 1, 2019 at 12:30 AM Nitish Saboo 
wrote:

> Hi,
>
> I want to convert *C.char to array of strings in Go.
> I want to do this because I want the first word from the string.Strings
> are getting appended to *C.char and I want the first word of the string.
> I am doing it using 'strings.Split(C.GoString(*C.char))[0]', but it is
> giving error.
> Can someone correct me 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.
> 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.

[go-nuts] Convert *C.char to array of strings in Go

[Nitish Saboo]

Hi,

I want to convert *C.char to array of strings in Go.
I want to do this because I want the first word from the string.Strings are 
getting appended to *C.char and I want the first word of the string.
I am doing it using 'strings.Split(C.GoString(*C.char))[0]', but it is 
giving error.
Can someone correct me 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Error gremlins

[jminter]

Hi,

I'm pretty sure little or none of this is particularly new but I haven't 
had much luck finding the canonical references.  I guess it's the age-old 
conversation about mechanical error checking vs backwards compatibility.  
Here are three ugly corner cases which I've bumped into recently:

1- return fmt.Errorf("net/http: HTTP/1.x transport connection broken: %v", 
err)
https://github.com/golang/go/blob/master/src/net/http/transport.go#L1651

Obviously, there's no shortage of cases like this in the standard library.  
Squashing the error means that the caller has to dissect the resulting 
string.  Is it planned that cases like this in the standard library will be 
moved from %v->%w?

2- var ErrTimeout error = &TimeoutError{}
https://github.com/golang/go/blob/master/src/internal/poll/fd.go#L37

Even though ErrTimeout looks exported, it's in an internal package so a 
caller can't import the package and check equivalence against the error.  
Again, caller has to dissect the resulting string.

3- type tlsHandshakeTimeoutError struct{}
https://github.com/golang/go/blob/master/src/net/http/transport.go#L2427

Not exported; again, caller has to dissect the resulting string.

Assuming that %v->%w is the answer for case 1 -- can anything be done to 
help cases 2 and 3?

Cheers,

Jim

-- 
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] Pass value from C code to GO code(CGO)

[ksbhaskar]

Nitish privately e-mailed me:

Can you please specify the particular files in YottaDB repository that are 
exchanging key-value pairs between C and Go ?

I am replying to the threadd.

Look at the buffer_t* and key_t* files. You can also trace the 
implementations of NodeNextE(), SubNextE(), NodeNextST(), and SubNextST().

Regards
– Bhaskar

On Monday, April 29, 2019 at 4:08:24 PM UTC-4, ksbh...@gmail.com wrote:
>
> Nitish –
>
> As noted, you cannot pass to C a pointer to Go structure. However, Go can 
> use pointers C structures that are provided to it. YottaDB passes key-value 
> tuples between C and Go, and you can look at working code that does this at 
> https://gitlab.com/YottaDB/Lang/YDBGo with further documentation at 
> https://docs.yottadb.com/MultiLangProgGuide/goprogram.html
>
> After looking at the code and documentation, if you have specific 
> questions, I can get them answered.
>
> Regards
> – Bhaskar
>
> On Monday, April 29, 2019 at 3:43:35 PM UTC-4, Tamás Gulácsi wrote:
>>
>> 2019. április 29., hétfő 17:41:51 UTC+2 időpontban Nitish Saboo a 
>> következőt írta:
>>>
>>> Hi Tamás,
>>>
>>> If I return LogMessage type of object from C code, what type of object 
>>> should be there on Go side to receive the return value because the Go side 
>>> doesn't have a LogMessage object  ?
>>>
>>> Thanks
>>>
>>>
>> That depends on what that LogMessage is.
>> If it is a struct, then you can get its fields.
>> And you can use that pointer in some C functions - this depends on the 
>> given API.
>>
>> If LogMessage is a struct, you may be able to convert it to its Go 
>> equivalent - if it is not too complicated (no union, no packing...).
>>
>

-- 
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] Re: Need help to launch hello.go

[andrey mirtchovski]

> PS F:\GoWorckspace\src\hello> go build -work
> WORK=E:\temp\go-build828919622
> open E:\temp\go-build828919622\b001\exe\a.out.exe: The system cannot find the 
> file specified.

once you have done this you should be able to cd to
E:\temp\go-build828919622 and look around to see if any files have
been created, including b001\exe\a.out.exe.

-- 
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: Need help to launch hello.go

[Avetis Sargsian]

GOPATH = F:\GoWorckspace
GOPATH dir structure is:
-bin/
-pkg/
-src/
 -hello/
hello.go

This is my home computer and cause is not an antivirus programm, I tried to 
reapit everising with it uninstalled.
And here is resul running build command with -work argument

PS F:\GoWorckspace\src\hello> go build -work
WORK=E:\temp\go-build828919622
open E:\temp\go-build828919622\b001\exe\a.out.exe: The system cannot find 
the file specified.

-- 
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] Re: Need help to launch hello.go

[andrey mirtchovski]

> PS F:\GoWorckspace\src\hello> go install
> open E:\temp\go-build447177998\b001\exe\a.out.exe: The system cannot find the 
> file specified.

is this a school or work computer? if yes then a group policy may have
disabled the execution of exe files. supply the "-work" argument to go
build. it will print the working directory and will not delete it
after finishing its run. then you can navigate to it and see if the
.exe file is there at all. i imagine, since only the .exe is the
problem, you will be able to see all the other temporary files that go
created.

-- 
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] Map inside a struct

[Jan Mercl]

On Tue, Apr 30, 2019 at 4:31 PM  wrote:

> In the method, I can debug and see that the struct got created with map and 
> its key value pair, however when the method returns to the caller, the struct 
> is there PI and cat initialised, but the key value pairs disappear from the 
> map. Is this behavior expected?

Plase show a minimal reproducer to help others help you.

Without that just a blind shot: calling a method that mutates its
receiver but is declared on a value receiver can have surprising
effects.

-- 
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] Map inside a struct

[mdmajid . jahangir]

I have a map inside a struct like following - 

type DP struct {
   PI string
   cat map[string]PS
}

Here, PS is another struct having two string fields.

There is method where I create DP struct, initialise the map and put a 
key-value pair to it.
I append this DP struct to an array and return from the method to its 
caller (the array to which i append is part of the object which is used to 
invoke the method).

In the method, I can debug and see that the struct got created with map and 
its key value pair, however when the method returns to the caller, the 
struct is there PI and cat initialised, but the key value pairs disappear 
from the map. Is this behavior expected? 

-- 
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: the Dominance of English in Programming Languages

[HaWe]

As others mentioned already, the 25 keywords in Go, which were taken from 
the english language are not a problem for (adult) programmers. And if they 
were, some kind of localized precompiler could handle them easily.

More of a stumbling block for non-english-native readers are names and 
comments in the code. I don't see a viable path to internationalization 
here. Technically yes, you could use 'gofmt -w'. But programming is 
internationally organized after all - you need a lingua franca. (Choosing 
names carefully can help a bit.)

But there is also the broad area of documentation to consider, especially 
API docs, namely the API docs of the Go Standard Library. I can imagine 
some kind of tooling, maybe an extension to 'go doc', that extracts 
localized text from supplemental files when they are available ... just an 
idea.
But, I already hear people say, programmers understand English - they have 
to. Yes, I agree ... partly. But you are much quicker to understand, to 
grok the Zen, when you read your own mother tongue. I can tell because on 
several occasions, for better to understand them, I underwent the effort to 
translate english written documents into German.
(BTW there is still a german version of The Go Programing Language waiting 
for a publisher: https://bitloeffel.de/index.php?lang=en)

But back to the topic of non-english programming languages. Time will tell. 
Programmers think about milliseconds, linguists think in centuries. If 
there is at some time a real need for, say, a Chinese based programming 
language then there will be one. You could even use Go to build the 
compiler.

my 2¢

-- 
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-dev] Try our new module mirror!

[Russ Cox]

On Tue, Apr 30, 2019 at 5:07 AM Jakub Cajka  wrote:

> > Our privacy policy explains how we collect and use your information. The
> > privacy policy for all of these services is proxy.golang.org/privacy.
>
> if I'm not mistaken the page that you are linking for privacy information
> of the proxy seems not related to it at all. It looks like some sort of
> generic terms that Google is using for all of its services. It is not
> describing what is collected and what for, how and where it is retained and
> stored, etc. in context of the proxy/this new google service.
>
> Could you expand on these topics in actual go proxy context, please? What
> are you collecting/are you planning on collecting and what for?
>

That's right - the privacy policy for the servers is currently Google's
standard privacy policy, so that URL is a simple redirect. We very much
want to provide more specific information in the future. When that happens,
proxy.golang.org/privacy will be updated to either redirect to the more
specific policy or serve it directly. That's all I can say right now.

> The module checksum database at sum.golang.org serves the URLs described
> in
> > the Secure the Public Go Module Ecosystem
> > 
>
>   With brief look on the proposal, just from the technical
> perspective(kind of including modules too). Little has changed from my
> perspective since the initial proposal. I'm still worried that I will have
> to disabled/de-configured or at worst case scenario even patch it (out) to
> make our build system in Fedora work with Go sources that we are
> curating/shipping/using(i.e. occasional need to carry downstream/backport
> patches). Leaving out for now the privacy/MITM concerns which look nearly
> the same(i.e. IMHO not resolved) as previously.
>

Yes, we still have open issues to address those various concerns. Note that
right now the proxy and checksum database are still disabled by default.
Even once they are enabled, all you need to do to bypass them is:

export GOPROXY=direct; export GONOSUMDB='*'

Now that the server is available for public alpha testing I intend to
circle back to trying to work out the best path forward for repackagers
like Fedora and for those concerned about privacy. It's easier to have
those conversations if you can show working code.

Is there anywhere a place where I or anyone else could pull the sources and
> contribute to all of these new Go features/services that you are
> deploying/running, or so I/anyone could potentially even run my own
> instances of proxy.golang.org, sum.golang.org and index.golang.org and
> help with devel?
>

There isn't right now, because they are tied a bit to Google infrastructure.
For proxy.golang.org, as I mentioned in my reply to Marwan, we intend to
publish a short reference proxy that people can adapt as needed, and of
course there is also Athens already.
For sum.golang.org, there is a reference implementation in
golang.org/cl/161665 and related CLs; those will land at
golang.org/x/exp/sumdb/... and eventually move to a more permanent location.
There's no reference for index.golang.org but it's little more than a
seekable append-only file.

Best,
Russ

-- 
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] Discrepancy between htop and memstats

[Michel Levieux]

Hi all,

I'm currently having a lot of trouble debugging the memory usage of the
program I'm working on. This program, everyday at a given time, reloads a
bunch of data (that's been updated by another program) into its memory. The
following function:

// PrintMemUsage outputs the current, total and OS memory being used. As
well as the number
// of garage collection cycles completed.
func PrintMemUsage() {
var m runtime.MemStats
runtime.ReadMemStats(&m)
// For info on each, see: https://golang.org/pkg/runtime/#MemStats
fmt.Printf("Alloc = %v MiB", bToMb(m.Alloc))
fmt.Printf("TotalAlloc = %v MiB", bToMb(m.TotalAlloc))
fmt.Printf("Sys = %v MiB", bToMb(m.Sys))
fmt.Printf("NumGC = %v\n", m.NumGC)
}

Outputs this:

Alloc = 103861 MiB
TotalAlloc = 6634355 MiB
Sys = 232088 MiB
NumGC = 3822

The program reloads its data everyday but everyday the few references that
existed for the given data is overwritten by the new one. And indeed the
"Alloc" line above seems to stay around 100GB. Where I don't understand
what happens is that in the htop line of the program, the memory that is
used by the program keeps growing as the days pass, and when it reaches
close to 100% percent of the host's memory, the program will crash
eventually.

Any idea that would help me debug this memory inconstency between memstats
and htop is welcome. I can also provide more information but no particular
piece of code directly from the project.

Thank you all in advance.

-- 
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: Get fingerprint of ca

[bucarr]

If I'm understanding your question correctly, this Youtube video from the 
2018 Gophercon should help: https://www.youtube.com/watch?v=kxKLYDLzuHA

On Tuesday, April 30, 2019 at 4:01:24 AM UTC-6, Vasiliy Tolstov wrote:
>
> Also if i use own root ca to issue intermediate cert that used for issue 
> client certs. How can i check that intermediate ca is issued by root ca?
>
> вт, 30 апр. 2019 г., 10:48 Vasiliy Tolstov  >:
>
>> Hi! May be i miss something, how can i get ca cert fingerprint in go via 
>> builtin packages if i have client cert issued via this ca?
>>
>

-- 
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] Need help to launch hello.go

[Robert Solomon]

I use win 10.  I have my code as subdirectories in src.  I see that you don't.  
Hello/ is not in src/.

And I then run go install from within src/

I also do this on ubuntu. 

-- 
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] binary.Read cgo fields

[Immueggpain S]

I guess I have no other choice then? BTW binary.Read shoud handle padding
automatically.

On Mon, Apr 22, 2019 at 10:53 AM Ian Lance Taylor  wrote:

> On Sat, Apr 20, 2019 at 11:53 AM  wrote:
> >
> > binary.Read can't set unexported fields, right?
> > But my structs are defined in C, and I can't make all C source code
> using capital fields..
> > What could I do?
>
> Read the fields separately.  That is often a better idea in any case,
> as the result is more portable and avoids problems with structs that
> require padding between fields.
>
> 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: Get fingerprint of ca

[Vasiliy Tolstov]

Also if i use own root ca to issue intermediate cert that used for issue
client certs. How can i check that intermediate ca is issued by root ca?

вт, 30 апр. 2019 г., 10:48 Vasiliy Tolstov :

> Hi! May be i miss something, how can i get ca cert fingerprint in go via
> builtin packages if i have client cert issued via this ca?
>

-- 
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] Cause of SIGBUS panic in gc?

[vaastav anand]

I was wrong about the gc not getting memory back from the goroutines. I 
think it does get that through the gcResetMarkState function.
So I don't think the # of goroutines are the issue..I'm sorry if I 
misled you

On Tuesday, 30 April 2019 00:28:29 UTC-7, vaastav anand wrote:
>
> The stack trace only lists goroutines that are not dead/not system 
> goroutines/not the goroutine that is calling the traceback function. 
> (src/runtime/traceback.go)
> Additionally, I don't think go reclaims any memory from dead goroutines. 
> allgs struct in src/runtime/proc.go file in the go source code holds all 
> the goroutines that have been created during the lifetime of the program 
> and it is all heap allocated. I don't know if the garbage collector 
> reclaims any of these dead goroutines. If it doesn't, which I don't think 
> it does because nothing ever seems to be removed from allgs.
>
> On Monday, 29 April 2019 23:54:54 UTC-7, Justin Israel wrote:
>>
>>
>>
>> On Tue, Apr 30, 2019 at 6:33 PM vaastav anand  
>> wrote:
>>
>>> I have encountered a SIGBUS with go before but I was hacking inside the 
>>> runtime and using shared mem with mmap.
>>>
>>> goroutines are assigned IDs incrementally and each goroutine at bare 
>>> minimum has 2.1KB stack space in go1.11 down from 2.7KB in go1.10 if I 
>>> recall correctly. So, at the very least at that point you could have easily 
>>> burnt through at least 7.5GB of memory. I am not sure what could happen if 
>>> you somehow exceed the amount of memory available. Seems like that is a 
>>> test you could write and see if launching more goroutines than that could 
>>> fit in the size of memory could actually cause a SIGBUS.
>>>
>>
>> The stack trace only listed 282 goroutines, which seems about right 
>> considering the number of clients that are connected. Its about 3 
>> goroutines per client connection, plus the other stuff in the server. I 
>> think it just indicates that I have turned over a lot of client connections 
>> over time. 
>>  
>>
>>>
>>> On Monday, 29 April 2019 23:25:52 UTC-7, Justin Israel wrote:



 On Tue, Apr 30, 2019 at 6:09 PM vaastav anand  
 wrote:

> Ok, so in the 2nd piece of code you posted, is some request being 
> pushed onto some OS queue? If so, is it possible that you may be maxing 
> the 
> queue out and then pushing something else into it and that could cause a 
> SIGBUS as well This seems super farfetched tho but it is hard to 
> debug 
> without really knowing what the application might really be doing.
>

 I want to say that I really appreciate you taking the time to try and 
 give me some possible ideas, even though this is a really vague problem. I 
 had only hoped someone had encountered something similar. 

 So that line in the SIGBUS crash is just trying to add a subscription 
 to a message topic callback in the nats client connection:
 https://godoc.org/github.com/nats-io/go-nats#Conn.Subscribe 
 It's pretty high level logic at my application level. 

 One thing that stood out to me was that in the crash, the goroutine id 
 number was 3538668. I had to double check to confirm that the go runtime 
 just uses an insignificant increasing number. I guess it does indicate 
 that 
 the application turned over > 3 mil goroutines by that point. I'm 
 wondering 
 if this is caused by something in the gnatsd embedded server (
 https://github.com/nats-io/gnatsd/tree/master/server) since most the 
 goroutines do come from that, with all the client handling going on. If we 
 are talking about something that is managing very large queues, that would 
 be the one doing so in this application.
  

>
> On Monday, 29 April 2019 22:57:40 UTC-7, Justin Israel wrote:
>>
>>
>>
>> On Tue, Apr 30, 2019 at 5:43 PM vaastav anand  
>> wrote:
>>
>>> I'd be very surprised if the anonymous goroutine is the reason 
>>> behind a SIGBUS violation.
>>> So, if I remember SIGBUS correctly, it means that you are issuing a 
>>> read/write to a memory address which is not really addressable or it is 
>>> misaligned. I think the chances of the address being misaligned are 
>>> very 
>>> low.so it really has to be a non-existent address.
>>> It can happen if you have try to access memory outside the region 
>>> mmaped into your application.
>>> If your application has any kind of mmap or shared memory access, I 
>>> would start there.
>>> In any case your best bet is to somehow reproduce the bug 
>>> consistently and then figure out which memory access is causing the 
>>> fault.
>>>
>>
>> My application isn't doing anything with mmap or shared memory, and 
>> my direct and indirect dependencies don't seem to be anything like that 
>> either. Its limited to pretty much nats.io client, gnatds embedded 
>>

[go-nuts] Re: [golang-dev] Try our new module mirror!

[Jakub Cajka]

- Original Message -
> From: "Katie Hockman" 
> To: golang-...@googlegroups.com
> Sent: Monday, April 29, 2019 10:35:38 PM
> Subject: [golang-dev] Try our new module mirror!
> 
> Hey Gophers!
> 
> In the blog post Go Modules in 2019 ,
> we announced our intent to provide a module mirror for accelerating Go
> module downloads, an index for discovering new modules, and a checksum
> database for authenticating module content.
> 
> We are excited to share that we are ready for developers to start alpha
> testing our module mirror, index, and checksum database!
> 
> Our privacy policy explains how we collect and use your information. The
> privacy policy for all of these services is proxy.golang.org/privacy.


Hello,

  if I'm not mistaken the page that you are linking for privacy information of 
the proxy seems not related to it at all. It looks like some sort of generic 
terms that Google is using for all of its services. It is not describing what 
is collected and what for, how and where it is retained and stored, etc. in 
context of the proxy/this new google service.

  Could you expand on these topics in actual go proxy context, please? What are 
you collecting/are you planning on collecting and what for?

> 
> The module mirror at proxy.golang.org serves the go command’s proxy
> protocol. To make the go command use it (when in module mode), set GOPROXY=
> https://proxy.golang.org.
> 
> The module index at index.golang.org serves a feed of module versions in
> the order they are discovered. For example, see
> https://index.golang.org/index?since=2019-03-04T18:00:15.161182-07:00
> 
> The module checksum database at sum.golang.org serves the URLs described in
> the Secure the Public Go Module Ecosystem
> 

  With brief look on the proposal, just from the technical perspective(kind of 
including modules too). Little has changed from my perspective since the 
initial proposal. I'm still worried that I will have to disabled/de-configured 
or at worst case scenario even patch it (out) to make our build system in 
Fedora work with Go sources that we are curating/shipping/using(i.e. occasional 
need to carry downstream/backport patches). Leaving out for now the 
privacy/MITM concerns which look nearly the same(i.e. IMHO not resolved) as 
previously.

> proposal. If you use the Go 1.13 development version of the go command,
> setting GOPROXY=https://proxy.golang.org will automatically use the
> checksum database as well. To use the checksum database to protect other
> code downloads, set GOSUMDB=sum.golang.org explicitly. See the development
> version go command docs
>  for
> details. If you are using Go 1.12 or earlier, you can manually check a
> go.sum file against the checksum database with gosumcheck
> :
> 
> go get golang.org/x/exp/sumdb/gosumcheck
> 
> gosumcheck /path/to/go.sum
> 
> We hope you’ll try out these new services! Note that these are in the early
> stages, so even though we don’t have any planned outages, you should
> recognize it is an alpha release and instability and bugs are expected.
> We’ll be actively working through these and improving our services, so
> please file issues  if you spot
> them, with the title prefix “proxy.golang.org:” (or index.golang.org, or
> sum.golang.org). We look forward to hearing about how it’s working for you!
> 
> Cheers,
> 
> Katie Hockman

  Is there anywhere a place where I or anyone else could pull the sources and 
contribute to all of these new Go features/services that you are 
deploying/running, or so I/anyone could potentially even run my own instances 
of proxy.golang.org, sum.golang.org and index.golang.org and help with devel?

  Thanks for any info. Sorry if I have missed some details.

JC


> 
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+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.

[go-nuts] Re: the Dominance of English in Programming Languages

[ffm2002]

"They" were also developing languages of their own, also in countries not 
of English language, such as Pascal, Modula, Scala (Switzerland), Kotlin 
(Russia) and using English words as key words. It is understood by everyone 
in the world who already knows some other language ;-).

Am Montag, 29. April 2019 15:37:45 UTC+2 schrieb fbaube:
>
> It's interesting to see this!
>
> Back in the early 1970s I wondered what the programming languages in other 
> countries (not-USA) looked like - what were the keywords, etc. 
>
> Well, it turns out that (AFAIK) they were using the same compilers and the 
> same interpreters, and languages with the same English keywords, because 
> (also AFAIK) nobody was writing non-English-keyword compilers in Europe and 
> nobody was patching existing binaries (like BASIC.EXE) to change the 
> keywords contained in executables.
>
> cheers - fred
>
> On Monday, April 29, 2019 at 11:58:50 AM UTC+3, yvan...@gmail.com wrote:
>>
>>
>> In France we have WINDEV  
>>
> giving something like
>> '''
>> // Le document sera enregistré en noir et blanc
>> SI TwainVersJPEG("C:\Temp\MaPhoto.JPEG", 0, Faux, TwainNoirBlanc) = Vrai 
>> ALORS
>> Info("Le document a été enregistré")
>> SINON
>> Erreur("Le document n'a pas été scanné")
>> FIN
>>
>

-- 
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] Get fingerprint of ca

[Vasiliy Tolstov]

Hi! May be i miss something, how can i get ca cert fingerprint in go via
builtin packages if i have client cert issued via this ca?

-- 
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] Cause of SIGBUS panic in gc?

[vaastav anand]

The stack trace only lists goroutines that are not dead/not system 
goroutines/not the goroutine that is calling the traceback function. 
(src/runtime/traceback.go)
Additionally, I don't think go reclaims any memory from dead goroutines. 
allgs struct in src/runtime/proc.go file in the go source code holds all 
the goroutines that have been created during the lifetime of the program 
and it is all heap allocated. I don't know if the garbage collector 
reclaims any of these dead goroutines. If it doesn't, which I don't think 
it does because nothing ever seems to be removed from allgs.

On Monday, 29 April 2019 23:54:54 UTC-7, Justin Israel wrote:
>
>
>
> On Tue, Apr 30, 2019 at 6:33 PM vaastav anand  > wrote:
>
>> I have encountered a SIGBUS with go before but I was hacking inside the 
>> runtime and using shared mem with mmap.
>>
>> goroutines are assigned IDs incrementally and each goroutine at bare 
>> minimum has 2.1KB stack space in go1.11 down from 2.7KB in go1.10 if I 
>> recall correctly. So, at the very least at that point you could have easily 
>> burnt through at least 7.5GB of memory. I am not sure what could happen if 
>> you somehow exceed the amount of memory available. Seems like that is a 
>> test you could write and see if launching more goroutines than that could 
>> fit in the size of memory could actually cause a SIGBUS.
>>
>
> The stack trace only listed 282 goroutines, which seems about right 
> considering the number of clients that are connected. Its about 3 
> goroutines per client connection, plus the other stuff in the server. I 
> think it just indicates that I have turned over a lot of client connections 
> over time. 
>  
>
>>
>> On Monday, 29 April 2019 23:25:52 UTC-7, Justin Israel wrote:
>>>
>>>
>>>
>>> On Tue, Apr 30, 2019 at 6:09 PM vaastav anand  
>>> wrote:
>>>
 Ok, so in the 2nd piece of code you posted, is some request being 
 pushed onto some OS queue? If so, is it possible that you may be maxing 
 the 
 queue out and then pushing something else into it and that could cause a 
 SIGBUS as well This seems super farfetched tho but it is hard to debug 
 without really knowing what the application might really be doing.

>>>
>>> I want to say that I really appreciate you taking the time to try and 
>>> give me some possible ideas, even though this is a really vague problem. I 
>>> had only hoped someone had encountered something similar. 
>>>
>>> So that line in the SIGBUS crash is just trying to add a subscription to 
>>> a message topic callback in the nats client connection:
>>> https://godoc.org/github.com/nats-io/go-nats#Conn.Subscribe 
>>> It's pretty high level logic at my application level. 
>>>
>>> One thing that stood out to me was that in the crash, the goroutine id 
>>> number was 3538668. I had to double check to confirm that the go runtime 
>>> just uses an insignificant increasing number. I guess it does indicate that 
>>> the application turned over > 3 mil goroutines by that point. I'm wondering 
>>> if this is caused by something in the gnatsd embedded server (
>>> https://github.com/nats-io/gnatsd/tree/master/server) since most the 
>>> goroutines do come from that, with all the client handling going on. If we 
>>> are talking about something that is managing very large queues, that would 
>>> be the one doing so in this application.
>>>  
>>>

 On Monday, 29 April 2019 22:57:40 UTC-7, Justin Israel wrote:
>
>
>
> On Tue, Apr 30, 2019 at 5:43 PM vaastav anand  
> wrote:
>
>> I'd be very surprised if the anonymous goroutine is the reason behind 
>> a SIGBUS violation.
>> So, if I remember SIGBUS correctly, it means that you are issuing a 
>> read/write to a memory address which is not really addressable or it is 
>> misaligned. I think the chances of the address being misaligned are very 
>> low.so it really has to be a non-existent address.
>> It can happen if you have try to access memory outside the region 
>> mmaped into your application.
>> If your application has any kind of mmap or shared memory access, I 
>> would start there.
>> In any case your best bet is to somehow reproduce the bug 
>> consistently and then figure out which memory access is causing the 
>> fault.
>>
>
> My application isn't doing anything with mmap or shared memory, and my 
> direct and indirect dependencies don't seem to be anything like that 
> either. Its limited to pretty much nats.io client, gnatds embedded 
> server, and a thrift rpc. 
>
> It seems so random that I doubt I could get a reproducible crash. So I 
> can really only try testing this on go 1.11 instead to see if any of the 
> GC 
> work in 1.12 causes this.
>
>
>>
>>
>> On Monday, 29 April 2019 21:59:34 UTC-7, Justin Israel wrote:
>>>
>>>
>>> On Thursday, November 29, 2018 at 6:22:56 PM UTC+13, Justin Israel 
>