Re: [go-nuts] Consume RESTful API Endpoints within a golang application with webtoken

['Benjamin' via golang-nuts]

Easy, Store the expired time in the token, and hash them.
When the expired time almost reach, use the old token to get a new token.


> On Mar 12, 2020, at 09:25, Renato Marcandier  
> wrote:
> 
> Hello guys,
> do you have any HelloWorld project in GO using RESTful to issue HTTP requests 
> from within a Golang application to remote RESTful/API with web token that 
> expires every 60 minutes and then consume any data that is returned?
> I am trying to get a simple HelloWorld. First, I need to do a POST to grab 
> the new token and after using this token to do a GET and see the response 
> with "Hello World!" using the following parameters:
> -
> POST:
> 
> Using:
> grant_type: password
> client_id: x
> client_secret: x
> username: x
> password: x
> 
> URL: 
> https://cloudsso.cisco.com/as/token.oauth2?grant_type=password_id=xx_secret==xxx=xx
>  
> 
> 
> Response:
> {
> "access_token": "tMqvXkR4wTvFwKUNUvMrNUXdzkjD",
> }
> 
> -
> GET:
> 
> Using: Bearer Token
> URL: https://api.cisco.com/hello 
> 
> Response:
> {"helloResponse":{"response":"Hello World!"}}
> 
> 
> Regards
> RG
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAGbJOOiT8fm7z6t5pNiFSmkXZy2KXs8Xdw-Cq0BkUD1CbUNExA%40mail.gmail.com
>  
> .

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4C76B950-358E-4E9D-ADE8-B681B7F2EC44%40icloud.com.

[go-nuts] Consume RESTful API Endpoints within a golang application with webtoken

[Renato Marcandier]

Hello guys,

do you have any HelloWorld project in GO using RESTful to issue HTTP
requests from within a Golang application to remote RESTful/API with web
token that expires every 60 minutes and then consume any data that is
returned?

I am trying to get a simple HelloWorld. First, I need to do a POST to grab
the new token and after using this token to do a GET and see the response
with "Hello World!" using the following parameters:

-

POST:


Using:

grant_type: password

client_id: x

client_secret: x

username: x

password: x


URL:
https://cloudsso.cisco.com/as/token.oauth2?grant_type=password_id=xx_secret==xxx=xx


Response:

{

"access_token": "tMqvXkR4wTvFwKUNUvMrNUXdzkjD",

}


-

GET:


Using: Bearer Token

URL: https://api.cisco.com/hello


Response:

{"helloResponse":{"response":"Hello World!"}}


Regards
RG

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGbJOOiT8fm7z6t5pNiFSmkXZy2KXs8Xdw-Cq0BkUD1CbUNExA%40mail.gmail.com.

Re: [go-nuts] Does recent bug in debug.FreeOSMemory also affect automatic background scavenging?

[johnmrusk]

Thanks Michael, 

That's super-helpful in helping us understand what to look for, and what 
not to look for.

I can't easily get sufficient data to file an issue right now, because the 
behaviour has only been reported in a customer environment that I don't 
have access to.  For that reason I can't even prove, yet, whether its a 
change in behavior or not.  Your reply makes it seem less likely to be a 
change, and more likely to be something else that was always there in our 
app but not previously reported.   If we get further into the 
investigation, and it does turn out to be a change in behaviour from the Go 
runtime, I'll definitely file an issue.

Thanks again for your answer.

John

On Thursday, March 12, 2020 at 3:35:26 PM UTC+13, Michael Knyszek wrote:
>
> Hi John,
>
> If you're referring to scavenging that kicked in every 2.5 minutes and 
> returned spans which had been unused for 5 minutes, that's been replaced 
> with an asynchronous, continuous mechanism as of Go 1.13 (
> https://github.com/golang/go/issues/30333). This policy is generally more 
> aggressive than the old one, so if you're seeing an increase in memory use 
> it's probably coming from something else. Do you know if this is an actual 
> increase in heap objects allocated (a GC trace would tell you 
> (GODEBUG=gctrace=1), also MemStats.HeapAlloc 
> ) or is that roughly the same 
> and the increase is only in OS-reported RSS?
>
> This new policy was also unaffected by the aforementioned bug.
>
> Please file an issue (https://github.com/golang/go/issues) and I'd be 
> happy to look into it. This isn't the first instance of an increase in 
> memory use we've seen in the issue tracker for Go 1.14, but right now it's 
> hard to tell where it's coming from. It doesn't appear to be the scavenger 
> in any of those other instances, also (AFAICT so far).
>
> Thanks,
> Michael
>
> On Wed, Mar 11, 2020 at 8:35 PM Ian Lance Taylor  > wrote:
>
>> [ +mknyszek ]
>>
>> On Wed, Mar 11, 2020 at 4:35 PM > wrote:
>> >
>> > I see this bug was recently fixed in FreeOSMemory: 
>> https://go-review.googlesource.com/c/go/+/208960/
>> >
>> > Does the same bug also affect the scavenging that automatically happens 
>> every 5 minutes?  Asking because we are seeing high memory usage, in an app 
>> that has (until now) avoided calling FreeOSMemory and just relied on the 
>> automatic 5-minute cleanup.
>> >
>> > John
>> >
>> > --
>> > 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 .
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/bb4bb2e7-9253-4034-b25f-6c1759b8d7dd%40googlegroups.com
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a1c685aa-7a90-4c69-b043-086967690b24%40googlegroups.com.

Re: [go-nuts] Does recent bug in debug.FreeOSMemory also affect automatic background scavenging?

['Michael Knyszek' via golang-nuts]

Hi John,

If you're referring to scavenging that kicked in every 2.5 minutes and
returned spans which had been unused for 5 minutes, that's been replaced
with an asynchronous, continuous mechanism as of Go 1.13 (
https://github.com/golang/go/issues/30333). This policy is generally more
aggressive than the old one, so if you're seeing an increase in memory use
it's probably coming from something else. Do you know if this is an actual
increase in heap objects allocated (a GC trace would tell you
(GODEBUG=gctrace=1), also MemStats.HeapAlloc
) or is that roughly the same and
the increase is only in OS-reported RSS?

This new policy was also unaffected by the aforementioned bug.

Please file an issue (https://github.com/golang/go/issues) and I'd be happy
to look into it. This isn't the first instance of an increase in memory use
we've seen in the issue tracker for Go 1.14, but right now it's hard to
tell where it's coming from. It doesn't appear to be the scavenger in any
of those other instances, also (AFAICT so far).

Thanks,
Michael

On Wed, Mar 11, 2020 at 8:35 PM Ian Lance Taylor  wrote:

> [ +mknyszek ]
>
> On Wed, Mar 11, 2020 at 4:35 PM  wrote:
> >
> > I see this bug was recently fixed in FreeOSMemory:
> https://go-review.googlesource.com/c/go/+/208960/
> >
> > Does the same bug also affect the scavenging that automatically happens
> every 5 minutes?  Asking because we are seeing high memory usage, in an app
> that has (until now) avoided calling FreeOSMemory and just relied on the
> automatic 5-minute cleanup.
> >
> > John
> >
> > --
> > 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.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/bb4bb2e7-9253-4034-b25f-6c1759b8d7dd%40googlegroups.com
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAFza%2Bu98D2Dg4hwZDqt1uf00tXd5iC2nrGvXSDYt_eJ5TQ5FNw%40mail.gmail.com.

Re: [go-nuts] Is this code in package unix assuming machine endianess?

[Rob Pike]

More context, in the form of self-promotion:
https://commandcenter.blogspot.com/2012/04/byte-order-fallacy.html

-rob


On Wed, Mar 11, 2020 at 9:42 PM Tom Parkin  wrote:

> On Tue, 10 Mar 2020 at 23:14, Ian Lance Taylor  wrote:
>
>> On Tue, Mar 10, 2020 at 4:03 PM Tom Parkin  wrote:
>> >
>> > I'm working on adding a new Linux socket type (L2TPIP) to the unix
>> package, and I noticed some code in there that appears on the face of it to
>> be assuming the endianess of the host.  The #networking channel on the
>> Gophers slack suggested I raise the question here.
>> >
>> > The code I am struggling with is in this file:
>> >
>> > https://github.com/golang/sys/blob/master/unix/syscall_linux.go
>> >
>> > So far as I can make out, this code implements a variety of system
>> calls for Linux generally, irrespective of GOARCH.
>> >
>> > In this file, there is a function anyToSockaddr which serves to convert
>> struct sockaddr from system calls such as getsockname(2) and accept4(2)
>> into Go representations of the various sockaddr types, for example
>> unix.SockaddrUnix and unix.SockaddrInet4.  The function anyToSockaddr
>> switches on the address family in the struct sockaddr, and then converts
>> based on that.
>> >
>> > I noticed for the AF_INET case in the switch statement of anyToSockaddr
>> that the struct sockaddr_in sin_port field is being unconditionally
>> byte-swapped during conversion:
>> >
>> > pp := (*RawSockaddrInet4)(unsafe.Pointer(rsa))
>> > sa := new(SockaddrInet4)
>> > p := (*[2]byte)(unsafe.Pointer())
>> > sa.Port = int(p[0])<<8 + int(p[1])
>> > for i := 0; i < len(sa.Addr); i++ {
>> > sa.Addr[i] = pp.Addr[i]
>> > }
>> > return sa, nil
>> >
>> > (where 'rsa' is a pointer to a RawSockaddrAny).
>> >
>> > Now, ip(7) states of the struct sockaddr_in structure:
>> >
>> >   "Note that the address and the port are always stored in network byte
>> order.  In particular, this means that you need to call htons(3) on the
>> number that is assigned to a port."
>> >
>> > So the byte swapping that anyToSockaddr is doing makes sense, but only
>> if the host is a little-endian machine.  It seems as though this code would
>> do the wrong thing on a big-endian machine.
>> >
>> > Can anyone suggest what I'm missing here?  Is this code really assuming
>> that the host is a little-endian machine?
>>
>> This does not look like byte swapping to me.  Here pp.Port should be
>> in network byte order.  To set sa.Port we read the first byte of
>> pp.Port, left shift by 8, then or in the second byte of pp.Port.  That
>> is, we interpret pp.Port as a two-byte big-endian number, and compute
>> the value as a 16-bit integer.  That will work regardless of the
>> endianness of the host.
>>
>
> Thanks Ian for your answer.
>
> It took me a little bit of thinking to get there :-( but I see what you're
> saying now.
>
> For anyone else playing along at home who may be struggling like I was...
>
> By treating the uint16 pp.Port value as an array of bytes, the code can
> access the bytes in network byte order, since that's how byte arrays are
> laid out in memory (e.g. if [0] is address A, [1] is A+1, etc).
>
> The left shift and addition effectively convert to host byte order, since
> that's how uint16 value will be stored in memory.
>
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CACzvQmaCcqfuZNyX43-%2Bb51z6bK8LLMrc7VxtLCMctBSg_fkJg%40mail.gmail.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOXNBZRq0H8Mfyi6WyHdawKZvo4UN49VOYF5UrtybkTj079RCA%40mail.gmail.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

[Ian Lance Taylor]

On Wed, Mar 11, 2020 at 6:44 AM 'Benjamin' via golang-nuts
 wrote:
>
> Why not merge https://go-review.googlesource.com/c/go/+/51670 since 2017?
> I tell you the truth: Workers of commercial  companies dislike the community 
> pull request, this will wast their free time or vacation time. They only 
> worked for capitalists.

The revision history of the Go project shows that this argument is
clearly incorrect.  There are numerous high quality contributions from
people who do not work at Google.

Regarding CL 51670 in particular, new assembly code for crypto
packages is a subject of ongoing discussion.  See, for example,
https://golang.org/issue/37168.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXuXBjYAxD7fL2Qp0S4TPayVR7HHzGMq81YGWozc%2B_O5A%40mail.gmail.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

[Adrian Ratnapala]

BTW: Thanks for all this investigation and writeups, they are
interesting, and I look forward to your test results.

Desipte my question, I think using a custom allocator is perfectly
reasonable.  go/issues/23199 is showing us that sync.Pool's interface
isn't great for allocating byte-bufffers (it'd be better to explicitly
ask for objects of a given size). In that sense, a custom allocator
with an appropriate interface is more future-proof.

> what I understand reading that issue is that sync.Pool is not the best
> choice to store variable-length buffers and my first allocator

I think the problem is that the total memory usage of the pool ends up
O(size of large objects * total numer of objects kept).  This is very
wasteful if you need lots of small objects and only a few large ones.

> implementation accepts buffers of any size, each received packet can
> have different sizes (between 20 and 262144 bytes).

So every 20 byte object will pin down ~100kiB of actual memory, which
sounds pretty wasteful, but might be acceptable.

> in general and currently, in my not yet public branch, I only allocate
> packets of 2 different sizes and so sync.Pool could be appropriate, I'll

You could have two separate pools, one for each size.  This is
basically a bucketed-allocator, but simpler because you already know
the structure of your buckets.


-- 
Adrian Ratnapala

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7jeDGUj%3DT8-n7RMuv2i_soHMJ78M8bWOpkVq_-g3n7v5g%40mail.gmail.com.

Re: [go-nuts] Does recent bug in debug.FreeOSMemory also affect automatic background scavenging?

[Ian Lance Taylor]

[ +mknyszek ]

On Wed, Mar 11, 2020 at 4:35 PM  wrote:
>
> I see this bug was recently fixed in FreeOSMemory: 
> https://go-review.googlesource.com/c/go/+/208960/
>
> Does the same bug also affect the scavenging that automatically happens every 
> 5 minutes?  Asking because we are seeing high memory usage, in an app that 
> has (until now) avoided calling FreeOSMemory and just relied on the automatic 
> 5-minute cleanup.
>
> John
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/bb4bb2e7-9253-4034-b25f-6c1759b8d7dd%40googlegroups.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUvxFW4sG413rgib2y%3DhWTy%2BrSdSWbsC6zby2qt2Kbs0A%40mail.gmail.com.

[go-nuts] Using modules with private repos

['Bryan C. Mills' via golang-nuts]

The protocol described in https://golang.org/cmd/go/#hdr-Remote_import_paths 
allows you to serve any repo URL for any import path that begins with your 
server's domain name.

You can use basic auth with such a server via credentials stored in a .netrc 
file, which also works with git.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b9fd9464-1347-4080-a4b6-c579fcf12913%40googlegroups.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

[Adrian Ratnapala]

> >
> > Any particular reason you avoided something like sync.Pool ? It could
be useful in your case, allocation pattern depending.
> >
>  Hi,
>
>  I initially evaluated the sync.Pool then I read this article:
>
> https://dzone.com/articles/memory-pooling-in-go-where-why-and-how
>
>  and this issue:
>
> https://github.com/golang/go/issues/23199

So If I understand go/issues/23199 correctly, the problem is that large
allocations from the past hang around in the pool (and apparently this is
made worse by small allocations somehow pinning them).

I can see how this can be a problem, but is it a problem *for you*?  You
say that the allocations in question are for packets  -- which I would
assume all count as small.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAN%2BHj7hWu7OH%2BhSm8KLX7o8au4Y%2BEpxpSmTYeuLHeQQ%2BMepGhg%40mail.gmail.com.

[go-nuts] FTE Remote Golang opportunity

[Dirk Zondag, Jr.]

Hello group-

I am working with an early stage startup looking for a Sr Distributed 
Systems SW Engineer. The office is in SF, but remote is AOK as well. You 
would be one of the first 10 people on board developing a groundbreaking 
serverless cloud and infrastructure. 

Main strengths needed being Golang, Kubernetes, Network/Sys design, and 
Cloud Infrastructure. 

It is a full time employee, direct hire position. If interested in hearing 
more, please just email me direct: d...@trailcreektechnology.com

Thank you for your time and interest.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/69a30962-224a-45fe-897d-03b8fb63afdc%40googlegroups.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

[Nicola Murino]

Il 11/03/20 22:55, Adrian Ratnapala ha scritto:

> >
> > Any particular reason you avoided something like sync.Pool ? It 
could be useful in your case, allocation pattern depending.

> >
>  Hi,
>
>  I initially evaluated the sync.Pool then I read this article:
>
> https://dzone.com/articles/memory-pooling-in-go-where-why-and-how
>
>  and this issue:
>
> https://github.com/golang/go/issues/23199

So If I understand go/issues/23199 correctly, the problem is that 
large allocations from the past hang around in the pool (and 
apparently this is made worse by small allocations somehow pinning them).


I can see how this can be a problem, but is it a problem *for you*?  
You say that the allocations in question are for packets  -- which I 
would assume all count as small.





what I understand reading that issue is that sync.Pool is not the best 
choice to store variable-length buffers and my first allocator 
implementation accepts buffers of any size, each received packet can 
have different sizes (between 20 and 262144 bytes).


As said before I'm reviewing the allocator and the allocation strategy 
in general and currently, in my not yet public branch, I only allocate 
packets of 2 different sizes and so sync.Pool could be appropriate, I'll 
do some more tests and benchmarks before submitting the pull request for 
the allocator,


thanks
Nicola


--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c24792b7-cf74-9bee-eabb-a3efef697089%40gmail.com.

[go-nuts] Does recent bug in debug.FreeOSMemory also affect automatic background scavenging?

[johnmrusk]

I see this bug was recently fixed in FreeOSMemory: 
https://go-review.googlesource.com/c/go/+/208960/

Does the same bug also affect the scavenging that automatically happens 
every 5 minutes?  Asking because we are seeing high memory usage, in an app 
that has (until now) avoided calling FreeOSMemory and just relied on the 
automatic 5-minute cleanup.

John

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bb4bb2e7-9253-4034-b25f-6c1759b8d7dd%40googlegroups.com.

Re: [go-nuts] Using modules with private repos

[Marcin Romaszewicz]

There is really no nicer way. You do not have to make those .insteadOf
overrides in your global git config, though, you can do it in the local git
config for your Go repository to contain the damage. You will also find
that private repositories don't work nicely with things like the Athens
module proxy, since you don't want your CI/CD systems hitting public
servers.

-- Marcin

On Wed, Mar 11, 2020 at 1:07 PM Dean Schulze 
wrote:

> The docs for modules assume that you'll be publishing your golang modules
> (actually a git push) to the few public repos that golang has built in
> support for.  I want to use a private repo, but there doesn't seem to be
> any docs for that.  This post
> 
>  has
> some suggestions, but it relies on entries in .gitcofig that will interfere
> with normal access to those public repos.  It doesn't mention using ssh
> keys for authentication.  I assume this is what go does for the public
> reops it has built in support for.
>
> I hope there is a better way.  Is there?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/c49ab83c-315c-4de1-9225-7f34d9cf395d%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtbpOFAHvqMX5bYSE8%2BinLCv7OeKxMmSZ5NcAwYkz_8zA%40mail.gmail.com.

[go-nuts] Using modules with private repos

[Dean Schulze]

The docs for modules assume that you'll be publishing your golang modules 
(actually a git push) to the few public repos that golang has built in 
support for.  I want to use a private repo, but there doesn't seem to be 
any docs for that.  This post 

 has 
some suggestions, but it relies on entries in .gitcofig that will interfere 
with normal access to those public repos.  It doesn't mention using ssh 
keys for authentication.  I assume this is what go does for the public 
reops it has built in support for.

I hope there is a better way.  Is there?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c49ab83c-315c-4de1-9225-7f34d9cf395d%40googlegroups.com.

Re: [go-nuts] Re: Where is the version number for a golang module declared?

[Dean Schulze]

Well here's what I get in my module with a single directory with a single 
file with a single package called lib:

$ go install lib
can't load package: package lib is not in GOROOT 
(/home/dean/bin/go1.14.linux-amd64/go/src/lib)

If I add the pwd to my GOPATH (the way things worked before modules) I get:

$ go install lib
$GOPATH/go.mod exists but should not

If I remove the go.mod file and give it the relative path to a source file 
it works but doesn't install anything:
$ go install src/lib/conf.reader.go 










On Wednesday, March 11, 2020 at 12:43:01 PM UTC-6, Bryan C. Mills wrote:
>
> `go install` does the same thing that it always has: it installs compiled 
> binaries and object files, not module source code. (A module may contain 
> multiple packages and multiple binaries.)
>
> See https://blog.golang.org/using-go-modules for a higher-level 
> introduction, and note that https://golang.org/doc/code.html is now 
> written for module mode rather than GOPATH mode.
>
> On Wed, Mar 11, 2020 at 2:33 PM Dean Schulze  > wrote:
>
>> Well, that was going to be my next question (how do I install a module 
>> from a local git repo or directory).
>>
>> If I understand you correctly go modules require a remote git repo, even 
>> if they are used only one machine.  That should be made clear in the docs.
>>
>> Modules get cached locally in $GOPATH/pkg/mod, but in my module directory 
>> of I do
>>
>> go install lib/conf.reader.go
>>
>> it completes without errors, but I don't get a binary or source code file 
>> anywhere under $GOPATH/pkg/mod (or anywhere else I can see).
>>
>> Does go install work differently with modules?
>>
>> On Wednesday, March 11, 2020 at 9:22:46 AM UTC-6, Bryan C. Mills wrote:
>>>
>>> On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w@gmail.com 
>>> wrote:
>>>
 This blog entry  uses 
 git tags.  It didn't mention branches.  Are tags the only way to declare a 
 version number?

>>>
>>> Yes, tags are the way to declare a version.
>>> Generally branches represent ongoing development: further commits may be 
>>> added without changing the branch name.
>>> In contrast, each version of a Go module must refer to one specific, 
>>> unchanging copy of the code.
>>> (That is important both for security and for reproducibility.)
>>>
>>> Also, what if my git repo is local to my laptop?  I'd think I should 
 still be able to publish versioned modules to my local GOPATH from my 
 local 
 git repo.

>>>  
>>> See https://golang.org/issue/28835, but in general we do not expect 
>>> users to need version selection for modules that are not published beyond a 
>>> single host.
>>>
>>> (But note that you can always set up a local HTTP server using the remote 
>>> import path  protocol, 
>>> and use a local DNS entry and the GOPRIVATE environment variable to tell 
>>> the Go command where to find the repo.)
>>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/eqEzMk5QFuk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/2eb95d66-b5e5-4640-a6cc-529189fe38ed%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c7efda8b-eba7-4906-96b5-0eca6790bb5c%40googlegroups.com.

Re: [go-nuts] Re: Where is the version number for a golang module declared?

['Bryan C. Mills' via golang-nuts]

`go install` does the same thing that it always has: it installs compiled
binaries and object files, not module source code. (A module may contain
multiple packages and multiple binaries.)

See https://blog.golang.org/using-go-modules for a higher-level
introduction, and note that https://golang.org/doc/code.html is now written
for module mode rather than GOPATH mode.

On Wed, Mar 11, 2020 at 2:33 PM Dean Schulze 
wrote:

> Well, that was going to be my next question (how do I install a module
> from a local git repo or directory).
>
> If I understand you correctly go modules require a remote git repo, even
> if they are used only one machine.  That should be made clear in the docs.
>
> Modules get cached locally in $GOPATH/pkg/mod, but in my module directory
> of I do
>
> go install lib/conf.reader.go
>
> it completes without errors, but I don't get a binary or source code file
> anywhere under $GOPATH/pkg/mod (or anywhere else I can see).
>
> Does go install work differently with modules?
>
> On Wednesday, March 11, 2020 at 9:22:46 AM UTC-6, Bryan C. Mills wrote:
>>
>> On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w@gmail.com
>> wrote:
>>
>>> This blog entry  uses
>>> git tags.  It didn't mention branches.  Are tags the only way to declare a
>>> version number?
>>>
>>
>> Yes, tags are the way to declare a version.
>> Generally branches represent ongoing development: further commits may be
>> added without changing the branch name.
>> In contrast, each version of a Go module must refer to one specific,
>> unchanging copy of the code.
>> (That is important both for security and for reproducibility.)
>>
>> Also, what if my git repo is local to my laptop?  I'd think I should
>>> still be able to publish versioned modules to my local GOPATH from my local
>>> git repo.
>>>
>>
>> See https://golang.org/issue/28835, but in general we do not expect
>> users to need version selection for modules that are not published beyond a
>> single host.
>>
>> (But note that you can always set up a local HTTP server using the remote
>> import path  protocol,
>> and use a local DNS entry and the GOPRIVATE environment variable to tell
>> the Go command where to find the repo.)
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/eqEzMk5QFuk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/2eb95d66-b5e5-4640-a6cc-529189fe38ed%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKWVi_QseRg3sHRp1AfHpUv2r65pafur7Jg8gprXkUxSxk8LmA%40mail.gmail.com.

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

Thanks for the links and summaries.  I had actually seen a few of those 
pages before.  The plasma demonstration at least provides some empirical 
evidence that as hacky as it is to convert binary→base-64 ASCII→binary for 
every frame update, the actual performance isn't too terrible.

On Wednesday, March 11, 2020 at 7:22:15 AM UTC-6, howar...@gmail.com wrote:
>
> His final verdict was that the pure Javascript version performed better 
> than the Go-WASM+JS version.
>

…which is not too surprising given the excessive data-format conversions 
and what makes me wonder if there isn't a more direct way—especially in 
newer versions of Go—to pass image data directly between Go and JavaScript.

Regards,
— Scott

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/751f1b77-5eee-4463-abeb-2281c153aaed%40googlegroups.com.

[go-nuts] Re: Where is the version number for a golang module declared?

[Dean Schulze]

Well, that was going to be my next question (how do I install a module from 
a local git repo or directory).

If I understand you correctly go modules require a remote git repo, even if 
they are used only one machine.  That should be made clear in the docs.

Modules get cached locally in $GOPATH/pkg/mod, but in my module directory 
of I do

go install lib/conf.reader.go

it completes without errors, but I don't get a binary or source code file 
anywhere under $GOPATH/pkg/mod (or anywhere else I can see).

Does go install work differently with modules?

On Wednesday, March 11, 2020 at 9:22:46 AM UTC-6, Bryan C. Mills wrote:
>
> On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w@gmail.com wrote:
>
>> This blog entry  uses git 
>> tags.  It didn't mention branches.  Are tags the only way to declare a 
>> version number?
>>
>
> Yes, tags are the way to declare a version.
> Generally branches represent ongoing development: further commits may be 
> added without changing the branch name.
> In contrast, each version of a Go module must refer to one specific, 
> unchanging copy of the code.
> (That is important both for security and for reproducibility.)
>
> Also, what if my git repo is local to my laptop?  I'd think I should still 
>> be able to publish versioned modules to my local GOPATH from my local git 
>> repo.
>>
>  
> See https://golang.org/issue/28835, but in general we do not expect users 
> to need version selection for modules that are not published beyond a 
> single host.
>
> (But note that you can always set up a local HTTP server using the remote 
> import path  protocol, 
> and use a local DNS entry and the GOPRIVATE environment variable to tell 
> the Go command where to find the repo.)
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2eb95d66-b5e5-4640-a6cc-529189fe38ed%40googlegroups.com.

Re: [go-nuts] Why can't I send byte array to golang TCP server using java netty client?

[wagner riffel]

I think that your problem is here: buffer := make([]byte, 6), conn.Read
reads up to len(bufer) before unblocking, and apparently you're trying
to decode an int32, which is 4 bytes long, so your Read call is waiting
for those 2 bytes from your java client to continue.

—wagner

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200311142230.71755059%40pampas.

[go-nuts] Re: Where is the version number for a golang module declared?

['Bryan C. Mills' via golang-nuts]

On Tuesday, March 10, 2020 at 5:47:45 PM UTC-4 dean.w@gmail.com wrote:

> This blog entry  uses git 
> tags.  It didn't mention branches.  Are tags the only way to declare a 
> version number?
>

Yes, tags are the way to declare a version.
Generally branches represent ongoing development: further commits may be 
added without changing the branch name.
In contrast, each version of a Go module must refer to one specific, 
unchanging copy of the code.
(That is important both for security and for reproducibility.)

Also, what if my git repo is local to my laptop?  I'd think I should still 
> be able to publish versioned modules to my local GOPATH from my local git 
> repo.
>
 
See https://golang.org/issue/28835, but in general we do not expect users 
to need version selection for modules that are not published beyond a 
single host.

(But note that you can always set up a local HTTP server using the remote 
import path  protocol, 
and use a local DNS entry and the GOPRIVATE environment variable to tell 
the Go command where to find the repo.)

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ec4a62b7-7ac3-47e5-a129-818fecf2554e%40googlegroups.com.

[go-nuts] Why can't I send byte array to golang TCP server using java netty client?

[tan winfan]

NioEventLoopGroup worker = new NioEventLoopGroup(); 
bootstrap.group(worker); bootstrap.channel(NioSocketChannel.class); 
bootstrap.handler(new ChannelInitializer() { @Override protected 
void initChannel(Channel channel) throws Exception { //BIG_ENDIAN 
channel.pipeline().addLast(new 
LengthFieldBasedFrameDecoder(ByteOrder.BIG_ENDIAN,1024*1024,2,2,-4,0,true)); 
channel.pipeline().addLast(new ClientHandler()); } }); ChannelFuture f = 
bootstrap.connect("127.0.0.1", 3000); //send msg byte[] msg = "I am java 
netty client msg".getBytes(); //If msg is a simple string, go can accept 
it. If it is changed to a byte array, go will block to conn.Read (buffer). 
f.channel().writeAndFlush(msg)



func main() { listen, err := net.Listen("tcp", "127.0.0.1:3") if err != 
nil { fmt.Println("listen failed, err:", err) return } defer listen.Close() 
for { conn, err := listen.Accept() if err != nil { fmt.Println("accept 
failed, err:", err) continue } go func() { defer conn.Close() var num int32 
buffer := make([]byte, 6) _, err := conn.Read(buffer) // If the byte [] 
byte copy sent by java netty is doubled in this line
if err != nil { return } buf := bytes.NewReader(buffer) err = 
binary.Read(buf, binary.BigEndian, ) fmt.Println(buf) }() } }

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9c7b7e3f-0e05-4aa4-9de9-6fad33fe56cf%40googlegroups.com.

[go-nuts] I have a question about #gokit and #tracing.

[Mahmood Tehrani]

When I use #opentracing in go kit just add in Zipkin or Jaeger one span and 
time duration whole a request but I wanna have per function one span. Have 
anybody experience in Gokit and tracing?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a67e5c85-25b4-4591-955c-551f5dfdd52e%40googlegroups.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

[Nicola Murino]

Il 11/03/20 15:23, Jesper Louis Andersen ha scritto:
On Wed, Mar 11, 2020 at 1:43 PM Nicola Murino > wrote:


So I wrote a proof of concept allocator that tries to avoid all
these extra allocations reusing the previously allocated slices:

https://github.com/drakkan/sftp/blob/master/allocator.go


Any particular reason you avoided something like sync.Pool ? It could 
be useful in your case, allocation pattern depending.



Hi,

I initially evaluated the sync.Pool then I read this article:

https://dzone.com/articles/memory-pooling-in-go-where-why-and-how

and this issue:

https://github.com/golang/go/issues/23199

so I decided to avoid the sync.Pool,

anyway I'm currently reviewing the allocator to submit a pull request 
against pkg/sftp, I'll probably do a quick test with the "sync.Pool" too 
and I'll take a look at the memory profiling results,


Nicola

--
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/239b0930-ada2-aedb-b08b-27925eefc423%40gmail.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

[Jesper Louis Andersen]

On Wed, Mar 11, 2020 at 1:43 PM Nicola Murino 
wrote:

> So I wrote a proof of concept allocator that tries to avoid all these
> extra allocations reusing the previously allocated slices:
>
> https://github.com/drakkan/sftp/blob/master/allocator.go
>
>
Any particular reason you avoided something like sync.Pool ? It could be
useful in your case, allocation pattern depending.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAGrdgiU%2BpUA8NOW1xsMbAjMDX9XrAaePxuq-EJvwM1Hj48opVQ%40mail.gmail.com.

Re: [go-nuts] Add "not null" parameter check and const variables/pointers

[Robert Engels]

Thinking about this over morning coffee it is more complex. It is not just 
sequential consistency that affects it - placing the struct in a map or some 
other reference container would also have to force a copy. 

Less and less utility. 

> On Mar 11, 2020, at 3:33 AM, Robert Engels  wrote:
> 
> True. But in the current situation, if the object was large, you either do a 
> copy (bad) or use a pointer and synchronize (worse?) - or you have to be 
> sequential. 
> 
> So, const could also carry with it sequential requirements (prohibited to be 
> captured by a Go routine), or alternatively, if captured a copy is made at 
> the time of capture (so you only pay the copy penalty in this case)
> 
> If you need to be concurrent and pass pointers around for performance you 
> need synchronized access anyway - so you are probably adding an access layer 
> anyway. 
> 
> To the OPs point, the “when to use a pointer receiver” in Go has always 
> struck me as a bit “loose” and in the wild many times creates either 
> performance issues or race conditions. Something like this might tighten it 
> up a bit.
> 
> 
> 
>>> On Mar 11, 2020, at 12:20 AM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Mar 10, 2020 at 10:08 PM robert engels  
>>> wrote:
>>> 
>>> I think what the OP was trying to say, is that with ‘const’ the compiler 
>>> could safely use a pointer receiver rather than a copy, and also enforce 
>>> that const are not modified, and only passed as const args (may require a 
>>> heap allocation though, so maybe only if struct is of a certain size based 
>>> on platform/compiler opts).
>>> 
>>> I think he has a point.
>>> 
>>> When you see a ‘pointer receiver’ a developer probably assumes the code 
>>> needs to modify the structs - thus you must pass a pointer. But if you are 
>>> only declaring a pointer to avoid an expensive large structure copy, you 
>>> are giving misleading information - and possibly causing bugs due to 
>>> incorrect later code modifications.
>> 
>> Thanks.  I don't see how to make that work, though.  Consider
>> 
>> type S struct { a [1]byte }
>> 
>> func (s const S) PrintLater() {
>>   go func() {
>>   time.Sleep(time.Second)
>>   fmt.Printf("%s\n", s.a)
>>   }()
>> }
>> 
>> func F() {
>>   var s S
>>   s.a[0] = 'a'
>>   s.PrintLater()
>>   s.a[0] = 'b'
>> }
>> 
>> With a value receiver the behavior is straightforward.  With a pointer
>> receiver this is a race condition.  With a const receiver, what is it?
>> It shouldn't be a race; after all, we've promised that the const
>> receiver won't modify the receiver.  So we have to copy the struct.
>> 
>> Ian
>> 
 On Mar 10, 2020, at 11:56 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Mar 10, 2020 at 9:49 PM 'aaa bbb' via golang-nuts
>>>  wrote:
>>> 
>>> 
>>> I test a code in go tour, and get a nil error at first:
>>> 
>>> 
>>> func say(s string, ch chan int) {
>>> 
>>> for i := 0; i <= 5; i++ {
>>> 
>>> time.Sleep(100 * time.Millisecond)
>>> 
>>> fmt.Println(s)
>>> 
>>> }
>>> 
>>> ch <- 1
>>> 
>>> }
>>> 
>>> 
>>> func main() {
>>> 
>>> 
>>> 
>>> //var ch chan int
>>> 
>>> var ch chan int = make(chan int, 1)
>>> 
>>> 
>>> 
>>> go say("world", ch)
>>> 
>>> fmt.Println("Hello")
>>> 
>>> <-ch
>>> 
>>> }
>>> 
>>> null reference error almost exists in every programming language.
>>> so why not make directive that indicates a parameter is not allowed nil? 
>>> like
>>> 
>>> func say(s string, ch chan int not nil) {...}
>>> 
>>> Or other more powerful validation mechanism.
>>> 
>>> 
>>> These kinds of issues have been discussed before.  See, for example,
>>> https://golang.org/issue/30177.
>>> 
>>> 
>>> also, at the value receiver and pointer receiver section, sometimes we 
>>> should use pointer
>>> receiver to avoid big memory copy. This is not a good solution, maybe there 
>>> should be a
>>> const keyword that stop modification the big struct and avoid big copy.
>>> 
>>> 
>>> People already have a way to avoid a big memory copy: use a pointer
>>> receiver.  It doesn't seem necessary to have a second way.
>>> 
>>> 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.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXrdGyYuUvymVyPyrpUujPr5Z0%2B3cxV6tz%3DmRZkHVLisg%40mail.gmail.com.
>>> 
>>> 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/C0AED78A-1473-44F5-B3F4-0015DB7608C2%40ix.netcom.com.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from 

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

['Benjamin' via golang-nuts]

Why not merge https://go-review.googlesource.com/c/go/+/51670 
 since 2017?
I tell you the truth: Workers of commercial  companies dislike the community 
pull request, this will wast their free time or vacation time. They only worked 
for capitalists.



> On Mar 11, 2020, at 20:58, 'Benjamin' via golang-nuts 
>  wrote:
> 
> I think that’s why go should be driven by the community but not by Bell labs 
> nor Google labs. 
> Works in Bell Labs or Google Labs may leave the job, and may not know 
> everything. 
> But the community have enough Human Resources and various of knowledges.
> 
> Some scientists and reaserchers  worked for commercial company for whole of 
> their life, but never do a things owned by themselves. Like Anders Hejlsberg, 
> the architect of Delphi and C#.  What a pity.
> 
> I think go programming language should also belongs to the community but not 
> Google. One day Bell Lab or Google are closed, the community still exists.
> 
> 
>> On Mar 11, 2020, at 20:43, Nicola Murino > > wrote:
>> 
>> Hi all,
>> 
>> I want to share the performances analysis I recently did for SFTPGo, the 
>> fully featured and highly configurable SFTP server written in Go 
>> (https://github.com/drakkan/sftpgo ).
>> 
>> When I decided to write an SFTP server I evaluated the available libraries 
>> and I did some quick performance tests too.
>> 
>> Golang's SSH stack and pkg/sftp were able to easily saturate a Gigabit 
>> connection and this seemed enough. I noticed that OpenSSH was faster, but I 
>> didn't investigate further.
>> 
>> So I chose Golang for SFTPGo.
>> 
>> The project is growing fast and one of the users also noticed that SFTPGo 
>> has lower performance than OpenSSH. He opened an issue providing some stats 
>> when using a 40Gb Ethernet card.
>> 
>> I did some more profiling and discovered that the main bottlenecks are, 
>> unsurprisingly, the cipher used and the message authentication. So we can 
>> have a huge performance boost using a fast cipher with implicit messages 
>> authentication, for example aes128-...@openssh.com 
>> , however this cipher is not widely supported.
>> 
>> The most used cipher, and the one used in the user's tests is AES-CTR, and 
>> the Golang implementations seems quite slow.
>> 
>> He noticed that an unmerged patch is available for Golang, greatly improving 
>> AES-CTR performance:
>> 
>> https://go-review.googlesource.com/c/go/+/51670 
>> 
>> 
>> I applied this patch and, while performance improved, the AES-CTR SFTP 
>> transfers were still slower than the AES-GCM ones. The bottleneck is now the 
>> MAC computation.
>> 
>> The tested hardware supports Intel SHA extensions but Golang's SHA256 
>> implementation only uses the AVX2 extension.
>> 
>> Again, I was lucky: I can simply use minio/sha256-simd as a drop-in 
>> replacement for Golang's SHA256 implementation:
>> 
>> https://github.com/drakkan/crypto/commit/17ef3d252b1c9d6124fa17889033e11eaa5c9ddb
>>  
>> 
>> 
>> The performance improved again, but OpenSSH was still faster.
>> 
>> To my great surprise I noticed that my very simple SCP implementation 
>> (https://github.com/drakkan/sftpgo/blob/master/sftpd/scp.go 
>> ) was now as 
>> fast as OpenSSH!
>> 
>> So this time I have to look at pkg/sftp: I found some extraneous 
>> copies/allocations in critical paths and I sent some pull requests that are 
>> now merged in the master branch. Still, SFTP transfers were slower than 
>> OpenSSH ones.
>> 
>> Compared to my SCP implementation the main difference is that pkg/sftp 
>> allocates a new slice for each SFTP packet, while my SCP implementation 
>> allocates a slice once and then reuses this slice. 
>> 
>> Basically for each SFTP packet pkg/sftp does something like this:
>> 
>> data := make([]byte, size)
>> 
>> So I wrote a proof of concept allocator that tries to avoid all these extra 
>> allocations reusing the previously allocated slices:
>> 
>> https://github.com/drakkan/sftp/blob/master/allocator.go 
>> 
>> 
>> And bingo! Now SFTPGo performance is very close to OpenSSH! You can find the 
>> full benchmark results here:
>> 
>> https://github.com/drakkan/sftpgo/blob/master/docs/performance.md 
>> 
>> 
>> Conclusion: I see several complaints about Go performance, especially 
>> compared to Rust, but, at least in my use case, Go can be as fast as a C 
>> project (such as OpenSSH). But some special attention is required and thus 
>> this improved performance is not by default available to all the users.
>> 
>> Now some questions:
>> 
>> 1) for the pkg/sftp 

[go-nuts] Re: Writing bitmap data to a canvas with WebAssembly

[howardcshaw]

I've no relevant experience, but I can recommend a couple of projects to 
look at in the absence of anyone chiming in with actual experience:

https://agniva.me/wasm/2018/06/18/shimmer-wasm.html
https://github.com/agnivade/shimmer
This is a play-project that involves loading images. It appears to be using 
a side-load method of converting the image to Base64 and assigning it to 
the image's src attribute - so it is not using the canvas directly, but if 
a call to the canvas can draw an image from a URL, this might work - have a 
look at

// updateImage writes the image to a byte buffer and then converts it to 
base64.
// Then it sets the value to the src attribute of the target image.
func (s *Shimmer) updateImage(img *image.RGBA, start time.Time) 

in https://github.com/agnivade/shimmer/blob/master/shimmer.go

Here is another project that also went with the Base64 method of passing 
the array, look for the section labeled "Pixels are Pixels": 
https://blog.jeremylikness.com/blog/2019-03-03_gopher-meet-plasma-a-webassembly-experiment/

His final verdict was that the pure Javascript version performed better 
than the Go-WASM+JS version.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3b8de1e9-f54a-4571-b14c-8d889e88bc6d%40googlegroups.com.

[go-nuts] Writing bitmap data to a canvas with WebAssembly

[Scott Pakin]

I'm new to WebAssembly and am trying to get Go to generate a bitmapped 
image to display in the Web browser.  Here's what I've come up with so far:

func DrawPicture(this js.Value, args []js.Value) interface{} {
// Create a canvas on the Web page.
const width = 256
const height = 256
canvas := js.Global().Get("document").Call("getElementById", 
"my-canvas")
canvas.Set("width", width)
canvas.Set("height", height)
canvas.Set("style", "border: thin solid black")
ctx := canvas.Call("getContext", "2d")
ctx.Call("clearRect", 0, 0, width, height)


// Render a picture.
imgData := ctx.Call("createImageData", width, height)
data := imgData.Get("data")
for y := 0; y < height; y++ {
for x := 0; x < width; x++ {
ofs := 4 * (y*width + x)
data.SetIndex(ofs+2, x+y)
data.SetIndex(ofs+3, 255)
}
}
ctx.Call("putImageData", imgData, 0, 0)
return nil
}

My question is: Is SetIndex 
 the most efficient way 
to write the image's pixels?  I see that syscall/js 
 provides a CopyBytesToJS 
 function, but I was 
unable to get that to work because the image data is a Uint8ClampedArray
 and CopyBytesToJS expects a Uint8Array.  I kept trying to populate a Go 
[]byte and transfer that to the image but never succeeded in making that 
work.

Thanks,
— Scott

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/78570dbf-9e6e-429b-a776-76ce50f5c7e2%40googlegroups.com.

Re: [go-nuts] SFTPGo: a Golang performance story and some questions

['Benjamin' via golang-nuts]

I think that’s why go should be driven by the community but not by Bell labs 
nor Google labs. 
Works in Bell Labs or Google Labs may leave the job, and may not know 
everything. 
But the community have enough Human Resources and various of knowledges.

Some scientists and reaserchers  worked for commercial company for whole of 
their life, but never do a things owned by themselves. Like Anders Hejlsberg, 
the architect of Delphi and C#.  What a pity.

I think go programming language should also belongs to the community but not 
Google. One day Bell Lab or Google are closed, the community still exists.


> On Mar 11, 2020, at 20:43, Nicola Murino  wrote:
> 
> Hi all,
> 
> I want to share the performances analysis I recently did for SFTPGo, the 
> fully featured and highly configurable SFTP server written in Go 
> (https://github.com/drakkan/sftpgo).
> 
> When I decided to write an SFTP server I evaluated the available libraries 
> and I did some quick performance tests too.
> 
> Golang's SSH stack and pkg/sftp were able to easily saturate a Gigabit 
> connection and this seemed enough. I noticed that OpenSSH was faster, but I 
> didn't investigate further.
> 
> So I chose Golang for SFTPGo.
> 
> The project is growing fast and one of the users also noticed that SFTPGo has 
> lower performance than OpenSSH. He opened an issue providing some stats when 
> using a 40Gb Ethernet card.
> 
> I did some more profiling and discovered that the main bottlenecks are, 
> unsurprisingly, the cipher used and the message authentication. So we can 
> have a huge performance boost using a fast cipher with implicit messages 
> authentication, for example aes128-...@openssh.com, however this cipher is 
> not widely supported.
> 
> The most used cipher, and the one used in the user's tests is AES-CTR, and 
> the Golang implementations seems quite slow.
> 
> He noticed that an unmerged patch is available for Golang, greatly improving 
> AES-CTR performance:
> 
> https://go-review.googlesource.com/c/go/+/51670
> 
> I applied this patch and, while performance improved, the AES-CTR SFTP 
> transfers were still slower than the AES-GCM ones. The bottleneck is now the 
> MAC computation.
> 
> The tested hardware supports Intel SHA extensions but Golang's SHA256 
> implementation only uses the AVX2 extension.
> 
> Again, I was lucky: I can simply use minio/sha256-simd as a drop-in 
> replacement for Golang's SHA256 implementation:
> 
> https://github.com/drakkan/crypto/commit/17ef3d252b1c9d6124fa17889033e11eaa5c9ddb
> 
> The performance improved again, but OpenSSH was still faster.
> 
> To my great surprise I noticed that my very simple SCP implementation 
> (https://github.com/drakkan/sftpgo/blob/master/sftpd/scp.go) was now as fast 
> as OpenSSH!
> 
> So this time I have to look at pkg/sftp: I found some extraneous 
> copies/allocations in critical paths and I sent some pull requests that are 
> now merged in the master branch. Still, SFTP transfers were slower than 
> OpenSSH ones.
> 
> Compared to my SCP implementation the main difference is that pkg/sftp 
> allocates a new slice for each SFTP packet, while my SCP implementation 
> allocates a slice once and then reuses this slice. 
> 
> Basically for each SFTP packet pkg/sftp does something like this:
> 
> data := make([]byte, size)
> 
> So I wrote a proof of concept allocator that tries to avoid all these extra 
> allocations reusing the previously allocated slices:
> 
> https://github.com/drakkan/sftp/blob/master/allocator.go
> 
> And bingo! Now SFTPGo performance is very close to OpenSSH! You can find the 
> full benchmark results here:
> 
> https://github.com/drakkan/sftpgo/blob/master/docs/performance.md
> 
> Conclusion: I see several complaints about Go performance, especially 
> compared to Rust, but, at least in my use case, Go can be as fast as a C 
> project (such as OpenSSH). But some special attention is required and thus 
> this improved performance is not by default available to all the users.
> 
> Now some questions:
> 
> 1) for the pkg/sftp allocator I'm discussing with pkg/sftp maintainers to 
> find a way to get it included. Do you have smarter ideas to avoid these 
> allocations?
> 2) There is a patch available for AES-CTR in Golang (since 2017): I wonder 
> why it is not yet merged?
> 3) To improve SHA computation performance, I cannot find anything usable in 
> Golang itself. Is there any plan to have support for Intel SHA Extensions and 
> AVX512 directly in Golang anytime soon?
> 
> Thank you for this great programming language, it makes it really simple to 
> add new features to SFTPGo!
> 
> regards,
> Nicola
> 
> -- 
> 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 
> .
> To view this discussion on the web visit 
> 

[go-nuts] SFTPGo: a Golang performance story and some questions

[Nicola Murino]

Hi all,

I want to share the performances analysis I recently did for SFTPGo, the 
fully featured and highly configurable SFTP server written in Go 
(https://github.com/drakkan/sftpgo).

When I decided to write an SFTP server I evaluated the available libraries 
and I did some quick performance tests too.

Golang's SSH stack and pkg/sftp were able to easily saturate a Gigabit 
connection and this seemed enough. I noticed that OpenSSH was faster, but I 
didn't investigate further.

So I chose Golang for SFTPGo.

The project is growing fast and one of the users also noticed that SFTPGo 
has lower performance than OpenSSH. He opened an issue providing some stats 
when using a 40Gb Ethernet card.

I did some more profiling and discovered that the main bottlenecks are, 
unsurprisingly, the cipher used and the message authentication. So we can 
have a huge performance boost using a fast cipher with implicit messages 
authentication, for example aes128-...@openssh.com, however this cipher is 
not widely supported.

The most used cipher, and the one used in the user's tests is AES-CTR, and 
the Golang implementations seems quite slow.

He noticed that an unmerged patch is available for Golang, greatly 
improving AES-CTR performance:

https://go-review.googlesource.com/c/go/+/51670

I applied this patch and, while performance improved, the AES-CTR SFTP 
transfers were still slower than the AES-GCM ones. The bottleneck is now 
the MAC computation.

The tested hardware supports Intel SHA extensions but Golang's SHA256 
implementation only uses the AVX2 extension.

Again, I was lucky: I can simply use minio/sha256-simd as a drop-in 
replacement for Golang's SHA256 implementation:

https://github.com/drakkan/crypto/commit/17ef3d252b1c9d6124fa17889033e11eaa5c9ddb

The performance improved again, but OpenSSH was still faster.

To my great surprise I noticed that my very simple SCP implementation 
(https://github.com/drakkan/sftpgo/blob/master/sftpd/scp.go) was now as 
fast as OpenSSH!

So this time I have to look at pkg/sftp: I found some extraneous 
copies/allocations in critical paths and I sent some pull requests that are 
now merged in the master branch. Still, SFTP transfers were slower than 
OpenSSH ones.

Compared to my SCP implementation the main difference is that pkg/sftp 
allocates a new slice for each SFTP packet, while my SCP implementation 
allocates a slice once and then reuses this slice. 

Basically for each SFTP packet pkg/sftp does something like this:

data := make([]byte, size)

So I wrote a proof of concept allocator that tries to avoid all these extra 
allocations reusing the previously allocated slices:

https://github.com/drakkan/sftp/blob/master/allocator.go

And bingo! Now SFTPGo performance is very close to OpenSSH! You can find 
the full benchmark results here:

https://github.com/drakkan/sftpgo/blob/master/docs/performance.md

Conclusion: I see several complaints about Go performance, especially 
compared to Rust, but, at least in my use case, Go can be as fast as a C 
project (such as OpenSSH). But some special attention is required and thus 
this improved performance is not by default available to all the users.

Now some questions:

1) for the pkg/sftp allocator I'm discussing with pkg/sftp maintainers to 
find a way to get it included. Do you have smarter ideas to avoid these 
allocations?
2) There is a patch available for AES-CTR in Golang (since 2017): I wonder 
why it is not yet merged?
3) To improve SHA computation performance, I cannot find anything usable in 
Golang itself. Is there any plan to have support for Intel SHA Extensions 
and AVX512 directly in Golang anytime soon?

Thank you for this great programming language, it makes it really simple to 
add new features to SFTPGo!

regards,
Nicola

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7cfdd60d-7415-4c2f-bd7d-9d0372461a3c%40googlegroups.com.

[go-nuts] Locked and closed issue 30400 but has it resolved the OPS report?

[Kevin Chadwick]

https://github.com/golang/go/issues/30400

It is still not clear without testing for yourself after the commit in the docs
that "(before umask)" is referring to using os.umask after file creation or the
executors inherited umask (secure reality).

The referenced Commit:
"https://github.com/golang/go/commit/4b05dc91b0fe99724721e3545807f3b8f1310c52;

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8568fb1e-37bf-ea8d-d0d7-8ecbdb05b826%40gmail.com.

Re: [go-nuts] Is this code in package unix assuming machine endianess?

[Tom Parkin]

On Tue, 10 Mar 2020 at 23:14, Ian Lance Taylor  wrote:

> On Tue, Mar 10, 2020 at 4:03 PM Tom Parkin  wrote:
> >
> > I'm working on adding a new Linux socket type (L2TPIP) to the unix
> package, and I noticed some code in there that appears on the face of it to
> be assuming the endianess of the host.  The #networking channel on the
> Gophers slack suggested I raise the question here.
> >
> > The code I am struggling with is in this file:
> >
> > https://github.com/golang/sys/blob/master/unix/syscall_linux.go
> >
> > So far as I can make out, this code implements a variety of system calls
> for Linux generally, irrespective of GOARCH.
> >
> > In this file, there is a function anyToSockaddr which serves to convert
> struct sockaddr from system calls such as getsockname(2) and accept4(2)
> into Go representations of the various sockaddr types, for example
> unix.SockaddrUnix and unix.SockaddrInet4.  The function anyToSockaddr
> switches on the address family in the struct sockaddr, and then converts
> based on that.
> >
> > I noticed for the AF_INET case in the switch statement of anyToSockaddr
> that the struct sockaddr_in sin_port field is being unconditionally
> byte-swapped during conversion:
> >
> > pp := (*RawSockaddrInet4)(unsafe.Pointer(rsa))
> > sa := new(SockaddrInet4)
> > p := (*[2]byte)(unsafe.Pointer())
> > sa.Port = int(p[0])<<8 + int(p[1])
> > for i := 0; i < len(sa.Addr); i++ {
> > sa.Addr[i] = pp.Addr[i]
> > }
> > return sa, nil
> >
> > (where 'rsa' is a pointer to a RawSockaddrAny).
> >
> > Now, ip(7) states of the struct sockaddr_in structure:
> >
> >   "Note that the address and the port are always stored in network byte
> order.  In particular, this means that you need to call htons(3) on the
> number that is assigned to a port."
> >
> > So the byte swapping that anyToSockaddr is doing makes sense, but only
> if the host is a little-endian machine.  It seems as though this code would
> do the wrong thing on a big-endian machine.
> >
> > Can anyone suggest what I'm missing here?  Is this code really assuming
> that the host is a little-endian machine?
>
> This does not look like byte swapping to me.  Here pp.Port should be
> in network byte order.  To set sa.Port we read the first byte of
> pp.Port, left shift by 8, then or in the second byte of pp.Port.  That
> is, we interpret pp.Port as a two-byte big-endian number, and compute
> the value as a 16-bit integer.  That will work regardless of the
> endianness of the host.
>

Thanks Ian for your answer.

It took me a little bit of thinking to get there :-( but I see what you're
saying now.

For anyone else playing along at home who may be struggling like I was...

By treating the uint16 pp.Port value as an array of bytes, the code can
access the bytes in network byte order, since that's how byte arrays are
laid out in memory (e.g. if [0] is address A, [1] is A+1, etc).

The left shift and addition effectively convert to host byte order, since
that's how uint16 value will be stored in memory.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CACzvQmaCcqfuZNyX43-%2Bb51z6bK8LLMrc7VxtLCMctBSg_fkJg%40mail.gmail.com.

Re: [go-nuts] An important proposal will fail without your support

[Dan Kortschak]

Ah, OK.

On Wed, 2020-03-11 at 01:58 -0700, miha.vrhov...@gmail.com wrote:
> https://github.com/golang/text/pull/9
> 
> And I cannot find the issue, but there are a few with extract command
> not working and crashing.
> 
> On Wednesday, March 11, 2020 at 9:40:36 AM UTC+1, kortschak wrote:
> > Why do you say that? 
> > 
> > ~/src/golang.org/x/text/message [master*]$ go env GO111MODULE 
> > on 
> > ~/src/golang.org/x/text/message [master*]$ go version 
> > go version go1.14 linux/amd64 
> > ~/src/golang.org/x/text/message [master*]$ go test 
> > PASS 
> > ok  golang.org/x/text/message0.024s 
> > 
> > 
> > On Wed, 2020-03-11 at 01:08 -0700, miha.v...@gmail.com wrote: 
> > > AFAIK this doesn't work in recent go versions and even less if
> > you 
> > > are using modules. 
> > > 
> > > On Wednesday, March 11, 2020 at 6:39:36 AM UTC+1, Tamás Gulácsi 
> > > wrote: 
> > > > Hi Jon, 
> > > > Have you read https://godoc.org/golang.org/x/text/message ? 
> > > > It's not gettext, but a better - though not perfect - solution
> > for 
> > > > this i18n problem. 
> > > 
> > > -- 
> > > 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. 
> > > To view this discussion on the web visit 
> > > 
> > https://groups.google.com/d/msgid/golang-nuts/e700071c-1138-439c-83c5-93eac98ecb0f%40googlegroups.com
> >  
> > > . 
> > 
> > 
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/1b001ff5-10ec-4d9e-a78e-c89b7b13b096%40googlegroups.com
> .


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8da96136cd869ad4159bb0553d1a16dbba046d2a.camel%40kortschak.io.

Re: [go-nuts] An important proposal will fail without your support

[miha . vrhovnik]

https://github.com/golang/text/pull/9

And I cannot find the issue, but there are a few with extract command not 
working and crashing.

On Wednesday, March 11, 2020 at 9:40:36 AM UTC+1, kortschak wrote:
>
> Why do you say that? 
>
> ~/src/golang.org/x/text/message [master*]$ go env GO111MODULE 
> on 
> ~/src/golang.org/x/text/message [master*]$ go version 
> go version go1.14 linux/amd64 
> ~/src/golang.org/x/text/message [master*]$ go test 
> PASS 
> ok  golang.org/x/text/message0.024s 
>
>
> On Wed, 2020-03-11 at 01:08 -0700, miha.v...@gmail.com  
> wrote: 
> > AFAIK this doesn't work in recent go versions and even less if you 
> > are using modules. 
> > 
> > On Wednesday, March 11, 2020 at 6:39:36 AM UTC+1, Tamás Gulácsi 
> > wrote: 
> > > Hi Jon, 
> > > Have you read https://godoc.org/golang.org/x/text/message ? 
> > > It's not gettext, but a better - though not perfect - solution for 
> > > this i18n problem. 
> > 
> > -- 
> > 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 . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/golang-nuts/e700071c-1138-439c-83c5-93eac98ecb0f%40googlegroups.com
>  
> > . 
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1b001ff5-10ec-4d9e-a78e-c89b7b13b096%40googlegroups.com.

Re: [go-nuts] An important proposal will fail without your support

[Dan Kortschak]

Why do you say that?

~/src/golang.org/x/text/message [master*]$ go env GO111MODULE 
on
~/src/golang.org/x/text/message [master*]$ go version
go version go1.14 linux/amd64
~/src/golang.org/x/text/message [master*]$ go test
PASS
ok  golang.org/x/text/message   0.024s


On Wed, 2020-03-11 at 01:08 -0700, miha.vrhov...@gmail.com wrote:
> AFAIK this doesn't work in recent go versions and even less if you
> are using modules.
> 
> On Wednesday, March 11, 2020 at 6:39:36 AM UTC+1, Tamás Gulácsi
> wrote:
> > Hi Jon,
> > Have you read https://godoc.org/golang.org/x/text/message ?
> > It's not gettext, but a better - though not perfect - solution for
> > this i18n problem.
> 
> -- 
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/e700071c-1138-439c-83c5-93eac98ecb0f%40googlegroups.com
> .


-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/369f907499fe1d1b86ab5d0c4135d192675c2488.camel%40kortschak.io.

Re: [go-nuts] An important proposal will fail without your support

[miha . vrhovnik]

AFAIK this doesn't work in recent go versions and even less if you are 
using modules.

On Wednesday, March 11, 2020 at 6:39:36 AM UTC+1, Tamás Gulácsi wrote:
>
> Hi Jon,
>
> Have you read https://godoc.org/golang.org/x/text/message ?
>
> It's not gettext, but a better - though not perfect - solution for this 
> i18n problem.
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e700071c-1138-439c-83c5-93eac98ecb0f%40googlegroups.com.

Re: [go-nuts] An important proposal will fail without your support

[Levieux Michel]

Hi Jon,

It seems you missed something here. "Please like my proposal or everyone
loses" is not an argument. We don't work that way here. You have suggested
the language needs a feature, and have gotten many answers from people that
think it does not.
Keeping on repeating the same argument forever will do nothing. Maybe there
is a real need for your change but in this case it looks like you need more
(different...) examples, and maybe a better approach.

But remember, when a lot of people tell you the same thing, if the only
reason you think of is "they don't see what I can see", first it *looks*
pretentious to the reader, and second, maybe, just maybe, you missed a
point. :)

Have a nice day.

Le mer. 11 mars 2020 à 06:40, Tamás Gulácsi  a écrit :

> Hi Jon,
>
> Have you read https://godoc.org/golang.org/x/text/message ?
>
> It's not gettext, but a better - though not perfect - solution for this
> i18n problem.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/8f667430-75ed-44a5-8e54-c1fa36398e5e%40googlegroups.com
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAL4P9zyTyYwmzMUey9fA-C9SVd3q_QeuqZV2qtWrE7GfcW%2Bu7A%40mail.gmail.com.

Re: [go-nuts] Add "not null" parameter check and const variables/pointers

[Robert Engels]

True. But in the current situation, if the object was large, you either do a 
copy (bad) or use a pointer and synchronize (worse?) - or you have to be 
sequential. 

So, const could also carry with it sequential requirements (prohibited to be 
captured by a Go routine), or alternatively, if captured a copy is made at the 
time of capture (so you only pay the copy penalty in this case)

If you need to be concurrent and pass pointers around for performance you need 
synchronized access anyway - so you are probably adding an access layer anyway. 

To the OPs point, the “when to use a pointer receiver” in Go has always struck 
me as a bit “loose” and in the wild many times creates either performance 
issues or race conditions. Something like this might tighten it up a bit. 



> On Mar 11, 2020, at 12:20 AM, Ian Lance Taylor  wrote:
> 
> On Tue, Mar 10, 2020 at 10:08 PM robert engels  wrote:
>> 
>> I think what the OP was trying to say, is that with ‘const’ the compiler 
>> could safely use a pointer receiver rather than a copy, and also enforce 
>> that const are not modified, and only passed as const args (may require a 
>> heap allocation though, so maybe only if struct is of a certain size based 
>> on platform/compiler opts).
>> 
>> I think he has a point.
>> 
>> When you see a ‘pointer receiver’ a developer probably assumes the code 
>> needs to modify the structs - thus you must pass a pointer. But if you are 
>> only declaring a pointer to avoid an expensive large structure copy, you are 
>> giving misleading information - and possibly causing bugs due to incorrect 
>> later code modifications.
> 
> Thanks.  I don't see how to make that work, though.  Consider
> 
> type S struct { a [1]byte }
> 
> func (s const S) PrintLater() {
>go func() {
>time.Sleep(time.Second)
>fmt.Printf("%s\n", s.a)
>}()
> }
> 
> func F() {
>var s S
>s.a[0] = 'a'
>s.PrintLater()
>s.a[0] = 'b'
> }
> 
> With a value receiver the behavior is straightforward.  With a pointer
> receiver this is a race condition.  With a const receiver, what is it?
> It shouldn't be a race; after all, we've promised that the const
> receiver won't modify the receiver.  So we have to copy the struct.
> 
> Ian
> 
>> On Mar 10, 2020, at 11:56 PM, Ian Lance Taylor  wrote:
>> 
>> On Tue, Mar 10, 2020 at 9:49 PM 'aaa bbb' via golang-nuts
>>  wrote:
>> 
>> 
>> I test a code in go tour, and get a nil error at first:
>> 
>> 
>> func say(s string, ch chan int) {
>> 
>> for i := 0; i <= 5; i++ {
>> 
>> time.Sleep(100 * time.Millisecond)
>> 
>> fmt.Println(s)
>> 
>> }
>> 
>> ch <- 1
>> 
>> }
>> 
>> 
>> func main() {
>> 
>> 
>> 
>> //var ch chan int
>> 
>> var ch chan int = make(chan int, 1)
>> 
>> 
>> 
>> go say("world", ch)
>> 
>> fmt.Println("Hello")
>> 
>> <-ch
>> 
>> }
>> 
>> null reference error almost exists in every programming language.
>> so why not make directive that indicates a parameter is not allowed nil? like
>> 
>> func say(s string, ch chan int not nil) {...}
>> 
>> Or other more powerful validation mechanism.
>> 
>> 
>> These kinds of issues have been discussed before.  See, for example,
>> https://golang.org/issue/30177.
>> 
>> 
>> also, at the value receiver and pointer receiver section, sometimes we 
>> should use pointer
>> receiver to avoid big memory copy. This is not a good solution, maybe there 
>> should be a
>> const keyword that stop modification the big struct and avoid big copy.
>> 
>> 
>> People already have a way to avoid a big memory copy: use a pointer
>> receiver.  It doesn't seem necessary to have a second way.
>> 
>> 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXrdGyYuUvymVyPyrpUujPr5Z0%2B3cxV6tz%3DmRZkHVLisg%40mail.gmail.com.
>> 
>> 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/C0AED78A-1473-44F5-B3F4-0015DB7608C2%40ix.netcom.com.