On Fri, 2021-10-08 at 16:36 -0700, Christian Stewart wrote:
> Is there a way to /not/ have this information in the binary?
>
You can use the garble tool[1] to strip/garble things like this.
$ cd golang.org/x/tools/cmd/stringer
$ garble build .
$ go version -m stringer
stringer: unknown
Yeah. I have a proof of concept complete. It's a bit more than 3 lines.
It's just under 100 lines. Error handling, etc.
1. This needs to be something devs can use without a lot of effort or they
just push back and use file-based HTTPS servers.
2. This needs to have no loss of
On Fri, Oct 8, 2021 at 12:36 PM Kamil Ziemian wrote:
>
> I found unimportant typo in English part of the documentation of "fmt". How
> can I correct it? GitHub pull request or open issue "Unimportant typos in
> documentation"? I don't know how I should treat such unimportant typo.
You can send
Is there a way to /not/ have this information in the binary?
On Friday, October 8, 2021 at 10:47:06 AM UTC-7 jayc...@google.com wrote:
> Good news! The main package path, the containing module, and all of the
> dependencies and their versions are already embedded in Go executables. You
> can
On Fri, 2021-10-08 at 15:33 -0700, Kamil Ziemian wrote:
> Hello,
>
> I now read documentation of "fmt" package and in "Format errors" (
> https://pkg.go.dev/fmt@go1.17.2#hdr-Format_errors) we have
> Invalid or invalid use of argument index: %!(BADINDEX)
> Printf("%*[2]d", 7):
Hi Kamil,
you can probably read it as Invalid argument index or invalid use of
argument index.
Hope that helps.
On 10/9/21 12:33 AM, Kamil Ziemian wrote:
Hello,
I now read documentation of "fmt" package and in "Format errors"
(https://pkg.go.dev/fmt@go1.17.2#hdr-Format_errors) we have
Hello,
I now read documentation of "fmt" package and in "Format errors"
(https://pkg.go.dev/fmt@go1.17.2#hdr-Format_errors) we have
Invalid or invalid use of argument index: %!(BADINDEX)
Printf("%*[2]d", 7): %!d(BADINDEX)
Printf("%.[2]d", 7): %!d(BADINDEX)
I cannot
Hello,
I found unimportant typo in English part of the documentation of "fmt". How
can I correct it? GitHub pull request or open issue "Unimportant typos in
documentation"? I don't know how I should treat such unimportant typo.
Best
Kamil
piątek, 8 października 2021 o 00:53:11 UTC+2 Kamil
On Fri, Oct 8, 2021 at 11:34 AM Davi Marcondes Moreira
wrote:
>
> Suppose a project has a package called abc, and this package has a few test
> files (*_test.go files).
>
> I've noticed two different patterns when writing tests. Some files may
> declare its own package at the top of the file as
>From https://pkg.go.dev/cmd/go#hdr-Test_packages
> Test files that declare a package with the suffix "_test" will be
compiled as a separate package, and then linked and run with the main test
binary.
Practically, this means no access to unexported things in the package
On Friday, October 8,
Suppose a project has a package called abc, and this package has a few test
files (*_test.go files).
I've noticed two different patterns when writing tests. Some files may
declare its own package at the top of the file as below:
package abc
While others may declare its package as:
package
net.TCPConn.SyscallConn exposes the fd which you can use with sycalls
On Friday, October 8, 2021 at 7:05:40 PM UTC+2 bjeun...@gmail.com wrote:
> Hi,
>
> looking at the net package of the standard library, I don't see a way to
> set the tcp max segment size. Surely, one can create a tcp
Good news! The main package path, the containing module, and all of the
dependencies and their versions are already embedded in Go executables. You
can read that info with `go version -m path/to/exe`.
$ go install golang.org/x/tools/cmd/stringer@latest
$ go version -m ~/go/bin/stringer
Hi,
looking at the net package of the standard library, I don't see a way to
set the tcp max segment size. Surely, one can create a tcp connection
manually and set the segment size by using the syscall package, but that
approach prevents them from reusing higher level packages that want a
One of my pet peeves with all executables, not just those created with go,
is that determining their origin can easily be lost in the mists of time.
This is a problem because I might "go get" some source code and install it,
then not update it for many years. Then when I have some need to do
Whatever the OS, the crucial question is whether the TCP connections get
reused, or whether a new TCP (and potentially TLS) connection has to be
negotiated, involving multiple round trips to the server.
Someone has kindly pointed out that the docs do spell out the behaviour - I
just missed the
I want to unmarshal an xml data to a data structure.
Problem is the following
This xml comes from a Odata Server and has fields "edmx:Edmx".
How should the fields of struct be named?
I observe that the fields name of struct representing xml should be the
same name as xml field name.
Now how
I'm using the library with a nosql. I provided the sql example b/c it's
part of the std library.
I like rog's solution(especially on the generic Resource type) but to
reduce friction and make it more idiomatic I would need to be able to
define the select arguments in the return func (after the
It's only 3 lines excluding error handling if you just want to use a static
string.
And you'll likely want to setting up your own http.Server anyway to have
control over timeouts (and also your own mux to prevent leaking debug
handlers).
In practice you may actually want o use
Sorry for the delayed response. I needed to noodle on this option and talk
to some of the devs who would need to implement this.
1. Setting up an http.Server{} and tls.Config will work. But it is a lot
of effort for devs who want to focus on the business logic.
2. This creates more code the
On Oct 7, 2021, at 3:36 AM, Amnon wrote:
>
> Is it necessary for a http client to fully read the http response body?
>
> Opinion on the Go forums seems divided
> https://forum.golangbridge.org/t/do-i-need-to-read-the-body-before-close-it/5594
>
> But a simple benchmark
21 matches
Mail list logo
