OT, but why do you want to support the Go 1.15 toolchain?
1.15 and 1.16 are no longer supported upstream, so will not get essential
security fixes.
Why not just ask your users to upgrade to 1.18.1?
On Tuesday, 10 May 2022 at 01:24:12 UTC+1 tapi...@gmail.com wrote:
> On Tuesday, May 10, 2022 at 1
On Tuesday, May 10, 2022 at 1:46:35 AM UTC+8 Ian Lance Taylor wrote:
> On Mon, May 9, 2022 at 10:18 AM tapi...@gmail.com
> wrote:
> >
> > I have a project using go1.16 embedding feature.
> > The project supports Go toolchain 1.15, by using "//go:build !go1.16"
> directive.
> >
> > Now I
Looking at proc-10451, I see that there are two mappings with anonymous
huge pages in that smaps output, and none on the other.
Does one machine have transparent hugepages enabled, and the other not?
You can check whether they're enabled on that system by looking
at /sys/kernel/mm/transparent_hugep
I didn't found the attachment here. Can you put it somewhere. Maybe as
github gist?
On Monday, May 9, 2022 at 4:18:52 AM UTC+2 garenchan wrote:
> /proc//limits of the two processes are the same.
> But /proc//smaps of the two processes are quite different, I have
> uploaded them to the attachme
On Mon, May 9, 2022 at 8:59 AM MQTT Tactic wrote:
>
> First I use LLVM PASS to extract all of the functions from the LLVM bitcode
> that compiled by `gollvm`. What I got is as follows:
>
> ```
> github_0com_1emitter_x2dio_1emitter_1internal_1security_1cipher._64_7uint8..eq
> github_0com_1emitter_
On Mon, May 9, 2022 at 10:18 AM tapi...@gmail.com wrote:
>
> I have a project using go1.16 embedding feature.
> The project supports Go toolchain 1.15, by using "//go:build !go1.16"
> directive.
>
> Now I have upgraded the toolchain to v1.18.1,
> And I want to debug the non-embedding flow of the
I have a project using go1.16 embedding feature.
The project supports Go toolchain 1.15, by using "//go:build !go1.16"
directive.
Now I have upgraded the toolchain to v1.18.1,
And I want to debug the non-embedding flow of the project.
Changing the go version in go.mod doesn't help.
Do I have to
tls.Conn.ConnectionState().PeerCertificates
- sean
On Mon, May 9, 2022, 16:59 J. Pecholt wrote:
> Hi there,
> I am trying to perform further authentication operations based on an
> existing tls.Conn without modifying the package/module itself because of
> portability and security reasons. More
Hi there,
I am trying to perform further authentication operations based on an
existing tls.Conn without modifying the package/module itself because of
portability and security reasons. More precisely, I want to know on the
server side if the client actually used a certificate to establish an
First I use LLVM PASS to extract all of the functions from the LLVM bitcode
that compiled by `gollvm`. What I got is as follows:
```
github_0com_1emitter_x2dio_1emitter_1internal_1security_1cipher._64_7uint8..eq
github_0com_1emitter_x2dio_1emitter_1internal_1security_1cipher._664_7uint8..eq
githu
Amit,
I know of a university professor and a university lecturer who use Go for
computational biology. They solve some interesting computer science
problems.
You say your code is efficient:
https://pkg.go.dev/github.com/fluhus/biostuff
I looked at your code and picked something simple:
I found the reason and also the solution for my problem. The reason is
simple enough: the draw.Draw method checks if the image has an alpha
channel and applies the composite operation as described in the article
above. For me the alpha channel for both end of the gradient image has been
set to
Sharing a package suite that I've written for my computational biology
research and may be useful for others.
Hope it helps!
https://pkg.go.dev/github.com/fluhus/biostuff
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this
13 matches
Mail list logo
