Re: [go-nuts] Distributed go testing (running "go test" as a client)

[Ian Lance Taylor]

On Mon, Oct 26, 2020 at 8:46 AM Craig Silverstein
 wrote:
>
> > You realize that the flag "-count 1" disable the cache, right?
>
> Well, it disables *a* cache.  The docs don't make it clear, but it
> seems like it only disables the test-cache.  I don't see why it would
> affect the build caches -- build time being my theory as to why the
> tests are slower.  But maybe it does?  Or maybe the extra time isn't
> being spent in building after all.

Hi Craig.

That's correct: -count 1 disables the test cache but not the build
cache.  But it does take some time to check all the source files and
verify that the build cache is correct.  Also, you can use "go test
-x" to see the commands that it is running.  Perhaps the build cache
is being invoked after all.  If there are commands being run, you can
get some idea of how long they take by using "go test
-toolexec=/usr/bin/time -x".

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/CAOyqgcWrFU7DLb6Nh%3D2b7yGP4C2sNX1j6hOujKy2qupDa40R9A%40mail.gmail.com.

[go-nuts] Re: Windows "syscalls" and Go pointers

[peterGo]

"I want to call RegisterClassW which takes a pointer to WNDCLASSW as its 
parameter. One of the members of WNDCLASSW is lpszClassName of LPCWSTR type 
(UTF-16 string). This puzzled me as to how I should approach allocating 
storage for that string?"


Win32 API:

RegisterClassW function: 
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerclassw

Registers a window class for subsequent use in calls to the CreateWindow or 
CreateWindowEx function.

Note:  The RegisterClass function has been superseded by the 
RegisterClassEx function. 

RegisterClassExW function: 
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-registerclassexw

Registers a window class for subsequent use in calls to the CreateWindow or 
CreateWindowEx function.


For RegisterClassExW you can take a look at the Go source code: 
https://go.googlesource.com/go

In src/runtime/syscall_windows_test.go:

func TestRegisterClass(t *testing.T) {
kernel32 := GetDLL(t, "kernel32.dll")
user32 := GetDLL(t, "user32.dll")
mh, _, _ := kernel32.Proc("GetModuleHandleW").Call(0)
cb := syscall.NewCallback(func(hwnd syscall.Handle, msg uint32, 
wparam, lparam uintptr) (rc uintptr) {
t.Fatal("callback should never get called")
return 0
})
type Wndclassex struct {
Size   uint32
Style  uint32
WndProcuintptr
ClsExtra   int32
WndExtra   int32
Instance   syscall.Handle
Icon   syscall.Handle
Cursor syscall.Handle
Background syscall.Handle
MenuName   *uint16
ClassName  *uint16
IconSm syscall.Handle
}
name := syscall.StringToUTF16Ptr("test_window")
wc := Wndclassex{
WndProc:   cb,
Instance:  syscall.Handle(mh),
ClassName: name,
}
wc.Size = uint32(unsafe.Sizeof(wc))
a, _, err := 
user32.Proc("RegisterClassExW").Call(uintptr(unsafe.Pointer()))
if a == 0 {
t.Fatalf("RegisterClassEx failed: %v", err)
}
r, _, err := 
user32.Proc("UnregisterClassW").Call(uintptr(unsafe.Pointer(name)), 0)
if r == 0 {
t.Fatalf("UnregisterClass failed: %v", err)
}
}

For lpszClassName:
 
name := syscall.StringToUTF16Ptr("test_window")

Peter


On Sunday, October 25, 2020 at 10:23:13 PM UTC-4 Constantine Shablya wrote:

> Hello,
>
> I wish to call some Windows functions, some of which take pointers to types
> which themselves contain pointers. For this purpose I intended to use
> golang.org/x/sys/windows/mkwinsyscall.go and not cgo; in past I have 
> implemented
> a package that uses WASAPI by generating "syscall" bodies with 
> mkwinsyscall.go
> and doing syscall.SyscallN to call virtual functions in COM objects and so 
> have
> some prior experience.
>
> Now I want to call RegisterClassW which takes a pointer to WNDCLASSW as its
> parameter. One of the members of WNDCLASSW is lpszClassName of LPCWSTR type
> (UTF-16 string). This puzzled me as to how I should approach allocating 
> storage
> for that string? Taking into account Go specification making special
> reservations for pointers passed to cgo calls
> (https://golang.org/cmd/cgo/#hdr-Passing_pointers; my guess is that it is
> intended to facilitate possible implementations of moving garbage 
> collectors in
> future) I thought I would have to allocate storage with, say, C.malloc, 
> but that
> would require using cgo which so far I have not had to use. I looked into 
> how Go
> standard library handles this, and I found crypto/x509/root_windows.go
> checkChainSSLServerPolicy
> (
> https://github.com/golang/go/blob/fa98f46741f818913a8c11b877520a548715131f/src/crypto/x509/root_windows.go#L103
> )
> build a chain of pointers and then pass it to
> syscall.CertVerifyCertificateChainPolicy, which is in violation of the cgo
> passing pointers requirement. Although this particular case does not use 
> cgo, I
> believe pointer passing restriction would still apply to it.
>
> All of this made me puzzled, should I store a pointer returned by
> syscall.UTF16PtrFromString (golang.org/x/sys/windows.UTF16PtrFromString) 
> or use
> C.malloc+copy? Or, if the answer isn't straightforward, is it fair to 
> think that
> use of pointer returned by UTF16PtrFromString is more likely to break with 
> newer
> versions of go than C.malloc+copy or is it expected that there will be some
> amendments made to that function when a hypothetical moving GC 
> implementation
> lands?
>
>

-- 
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 

Re: [go-nuts] Using Golang to upload and download files in pcloud using cmd

[Dimas Prawira]

I think the example given in the repo is run on command line, all you have
to do is customize it using cobra https://github.com/spf13/cobra



On Mon, Oct 26, 2020, 23:27 Bharath Baiju  wrote:

> Hello all,
>
> I am trying to use golang-pcloud  project
> to upload and download files.With this i can upload my files but
> downloading is not working.
>
> Also when using this i can upload small size of files but when it is more
> than 50mb it is taking more time.
>
> Is there any other method by using golang to connect to pcloud in cmd.Can
> anybody help me ?
>
> Regards
> Bharath baiju
>
> --
> 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/4b65dd97-0636-4a31-893f-618181a9ac68n%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%2Bp%2BMUfzQ%2BpcirNzgkn5CPf6FN0wpM3ZkagiFOawiMQAJH5z4A%40mail.gmail.com.

Re: [go-nuts] Does concurrency have some effect over HTTP client?

[JuanPablo AJ]

Jesper, 
thanks a lot for your email, your answer was a hand in the dark forest of 
doubts.

I will start trying the load generator wrk2.

About "instrument, profile, observe", yes, I added the gops agent but until 
now I don't have any conclusion related to that information.

Regards.


On Sunday, October 25, 2020 at 8:07:58 AM UTC-3 jesper.lou...@gmail.com 
wrote:

> On Sat, Oct 24, 2020 at 7:30 PM JuanPablo AJ  wrote:
>  
>
>> I have some doubts related to the HTTP client.
>>
>
> First, if you have unexplained efficiency concerns in a program, you 
> should profile and instrument. Make the system tell you what is happening 
> rather than making guesses as to why. With that said, I have some hunches 
> and experiments you might want to try out.
>
> When you perform a load test, you have a SUT, or system-under-test. That 
> is the whole system, including infrastructure around it. I can be a single 
> program, or a cluster of machines. You also have a load generator, which 
> generates load on your SUT in order to test different aspects of the SUT: 
> bandwidth usage, latency in response, capacity limits, resource limits, 
> etc[1]. Your goal is to figure out if the data you are seeing are within an 
> acceptable range for your use case, or if you have to work more on the 
> system to make it fall within the acceptable window. 
>
> Your test is about RTT latency of requests. This will become important.
>
> One particular problem in your test is that the load generator and the SUT 
> runs in the same environment. If the test is simple and you are trying to 
> stress the system maximally, chances are that the load generator impacts 
> the SUT. That means the latency will rise due to time sharing in the 
> operating system.
>
> Second, when measuring latency you should look out for the problem Gil 
> Tene coined as "coordinated omission". In CO, the problem is that the load 
> generator and the SUT cooperates in order to deliver the wrong latency 
> counts. This is especially true if you just fire as many requests as 
> possible on 50 connections. Under an overload situation, the system will 
> suffer in latency since that is the only way the system can alleviate 
> pressure. The problem with CO is that a server can decide to park a couple 
> of requests and handle the other requests as fast as possible. This can 
> load to a high number of requests on the active connections, and the 
> stalled connections become noise in the statistics. You can look up Tene's 
> `wrk2` project, but I think the ideas were baked back into Will 
> Glozers wrk at a later point in time (memory eludes me).
>
> The third point is about the sensitivity of your tests: when you measure 
> things at the millisecond, microsecond or nanosecond range, your test 
> becomes far more susceptible to foreign impact. You can generally use 
> statistical bootstrapping to measure the impact this has on test variance, 
> which I've done in the past. You start finding all kinds of interesting 
> corner cases that perturb your benchmarks. Among the more surprising ones:
>
> * CPU Scaling governors
> * Turbo boosting: one core can be run at a higher clock frequency than a 
> cluster. GC in Go is multicore, so even for a single-core program, this 
> might have an effect
> * CPU heat. Laptop CPUs have miserable thermal cooling compared to a 
> server or desktop. They can run fast in small bursts, but not for longer 
> stretches
> * Someone using the computer while doing the benchmark
> * An open browser window which runs some Javascript in the background
> * An open electron app with a rendering of a .gif or .webm file
> * Playing music while performing the benchmark, yielding CPU power to the 
> MP3, Vorbis or AAC decoder
> * Amount of incoming network traffic to process for a benchmark that has 
> nothing to do with the network
>
> Finally, asynchronous goroutines are still work the program needs to 
> execute. It isn't free. So as the system is stressed with a higher load you 
> run higher against the capacity limit, thus incurring slower response 
> times. In the case where you perform requests in the background to another 
> HTTP server, you are taking a slice of the available resources. You are 
> also generating as much work internally as is coming in externally. In a 
> real world server, this is usually a bad idea and you must put a resource 
> limit in place. Otherwise an aggressive client can overwhelm your server. 
> The trick is to slow the caller down by *not* responding right away if you 
> are overloaded internally.
>
> You should check your kernel. When you perform a large amount of requests 
> on the same machine, you can run into limits in the number of TCP source 
> ports if they are rotated too fast. It is a common problem when the load 
> generator and SUT are on the same host.
>
> You should check your HTTP client configuration as well. One way to avoid 
> the above problem is to maximize connection reuse, but then you risk 
> 

Re: [go-nuts] Better generator support

['Axel Wagner' via golang-nuts]

On Mon, Oct 26, 2020, 19:05 Oliver Smith 
wrote:

>
> Hi Axel, thanks for replying;
>
> It isn't a pattern I teach anyone, rather it's a pattern which people I'm
> encouraging to learn golang ask me about. Frequently. I was also under the
> impression that generally passing a send-only channel to a function could
> typically be considered an indicator the caller retains responsibility for
> closing the channel.
>

The fact that there is no real clarity on that is exactly why I would
advise against exposing channels in an API.


On Sunday, October 25, 2020 at 5:18:27 PM UTC-7 axel.wa...@googlemail.com
> wrote:
>
>> On Mon, Oct 26, 2020 at 12:29 AM Oliver Smith <
>> oliver...@superevilmegacorp.com> wrote:
>>
>>> This pattern/idiom is very un-golike in that it's an eyesore, and one of
>>> the hardest things I've found to teach people new to trying to read go code.
>>>
>>
>> FWIW, I definitely disagree that this is somehow "un-golike"
>> (non-specific, subjective terms like this have exactly this problem - no
>> one really knows what it means). And I mostly disagree that it's a
>> particularly bad problem - I can see where you are coming from, but at
>> worst, this seems a minor issue, not worth changing the language for.
>>
>> I would also recommend against teaching this to newcomers to the
>> language. Returning a channel in this way has a couple of issues - among
>> others, it doesn't allow the caller to control buffering of the channel.
>> This can be solved (which also, IMO, solves your readability issues) by
>> instead *taking* a channel to write to:
>>
>> func filterPositiveOdds(numbers []int, ch chan<- int) {
>> defer close(channel)
>> for _, value := range numbers {
>> if value > 0 && (value & 1) == 1 {
>> channel <- value
>> }
>> }
>> }
>>
>> func caller() {
>> var numbers []int
>> ch := make(chan int)
>> go filterPositiveOdds(numbers, ch)
>> for n := range ch {
>> }
>> }
>>
>> This has fundamentally the same control-flow, but we give a name to the
>> function, thus making it clearer, what the extra goroutine is for.
>>
>> However, IMO this is still bad form. In general, I would advise exposing
>> channels in APIs. It requires you to specify extra properties, like "what
>> happens if the channel blocks" or "how does the operation get cancelled" in
>> the documentation, without a way to get correctness compiler-checked. In
>> particular, the code (both mine and yours) suffers from exactly these
>> problems - if the channel is not consumed, we leak a goroutine and there is
>> no way to prematurely abort consumption. Getting an error back is even
>> worse.
>>
>> A better way is to provide a simple, synchronous iterator API like
>> bufio.Scanner  does.
>> For example, you could have
>>
>> type IntIterator struct {
>> numbers []int
>> }
>>
>> func FilterPositiveOdds(numbers []int) *IntIterator {
>> return {numbers}
>> }
>>
>> func (it *IntIterator) Next() (n int, ok bool) {
>> for _, n := range it.numbers {
>> it.numbers = it.numbers[1:]
>> if (n > 0 || n & 1 != 0) {
>> return n, true
>> }
>> }
>> return 0, false
>> }
>>
>> In complex cases, concurrency can be hidden behind the iterator API. In
>> simple cases, you could also reduce boilerplate by doing
>>
>> func FilterPositiveOdds(numbers []int) (next func() (n int, ok bool)) {
>> return func() (n int, ok bool) {
>> // same as above, but closing over numbers
>> }
>> }
>>
>> In any case - if you are unhappy with your pattern, there are many
>> alternatives to choose from, within the language as it exists today. It
>> seems hardly worth extra language features, to simplify this IMO rather
>> uncommon construct.
>>
>>
>>
>>> I've toyed with a few alternatives, but I'm having a hard time finding
>>> something I think everyone would like.
>>>
>>> Pattern the first; 'go return` which flips the idiom with syntactic
>>> sugar. 'go return' returns the function and continues the remainder of it
>>> in a go func() { ... }
>>>
>>> ```go
>>> func getPositiveOdds(numbers []int) <-chan int {
>>> channel := make(chan int)
>>> go return channel
>>>
>>> defer close(channel)
>>> for _, value := range numbers {
>>> if value > 0 && (value & 1) == 1 {
>>> channel <- value
>>> }
>>> }
>>> }
>>> ```
>>>
>>> The second more closely binds to the channel-generator pattern by
>>> extending make(chan) to take a 'go func' parameter:
>>>
>>> ```go
>>> func getPositiveOdds(numbers []int) <-chan int {
>>> generator := make(chan int, go func (channel chan int) {
>>> defer close(channel)
>>> for _, value := range numbers {
>>> if value > 0 && (value & 1) == 1 {
>>> channel <- value
>>> }
>>> }
>>> })
>>> return generator
>>> }
>>> ```
>>>
>>> I was tempted by the notion of 

Re: [go-nuts] Better generator support

[Oliver Smith]

Hi Axel, thanks for replying;

It isn't a pattern I teach anyone, rather it's a pattern which people I'm 
encouraging to learn golang ask me about. Frequently. I was also under the 
impression that generally passing a send-only channel to a function could 
typically be considered an indicator the caller retains responsibility for 
closing the channel.
On Sunday, October 25, 2020 at 5:18:27 PM UTC-7 axel.wa...@googlemail.com 
wrote:

> On Mon, Oct 26, 2020 at 12:29 AM Oliver Smith <
> oliver...@superevilmegacorp.com> wrote:
>
>> This pattern/idiom is very un-golike in that it's an eyesore, and one of 
>> the hardest things I've found to teach people new to trying to read go code.
>>
>
> FWIW, I definitely disagree that this is somehow "un-golike" 
> (non-specific, subjective terms like this have exactly this problem - no 
> one really knows what it means). And I mostly disagree that it's a 
> particularly bad problem - I can see where you are coming from, but at 
> worst, this seems a minor issue, not worth changing the language for.
>
> I would also recommend against teaching this to newcomers to the language. 
> Returning a channel in this way has a couple of issues - among others, it 
> doesn't allow the caller to control buffering of the channel. This can be 
> solved (which also, IMO, solves your readability issues) by instead 
> *taking* a channel to write to:
>
> func filterPositiveOdds(numbers []int, ch chan<- int) {
> defer close(channel)
> for _, value := range numbers {
> if value > 0 && (value & 1) == 1 {
> channel <- value
> }
> }
> }
>
> func caller() {
> var numbers []int
> ch := make(chan int)
> go filterPositiveOdds(numbers, ch)
> for n := range ch {
> }
> }
>
> This has fundamentally the same control-flow, but we give a name to the 
> function, thus making it clearer, what the extra goroutine is for.
>
> However, IMO this is still bad form. In general, I would advise exposing 
> channels in APIs. It requires you to specify extra properties, like "what 
> happens if the channel blocks" or "how does the operation get cancelled" in 
> the documentation, without a way to get correctness compiler-checked. In 
> particular, the code (both mine and yours) suffers from exactly these 
> problems - if the channel is not consumed, we leak a goroutine and there is 
> no way to prematurely abort consumption. Getting an error back is even 
> worse.
>
> A better way is to provide a simple, synchronous iterator API like 
> bufio.Scanner  does.
> For example, you could have
>
> type IntIterator struct {
> numbers []int
> }
>
> func FilterPositiveOdds(numbers []int) *IntIterator {
> return {numbers}
> }
>
> func (it *IntIterator) Next() (n int, ok bool) {
> for _, n := range it.numbers {
> it.numbers = it.numbers[1:]
> if (n > 0 || n & 1 != 0) {
> return n, true
> }
> }
> return 0, false
> }
>
> In complex cases, concurrency can be hidden behind the iterator API. In 
> simple cases, you could also reduce boilerplate by doing
>
> func FilterPositiveOdds(numbers []int) (next func() (n int, ok bool)) {
> return func() (n int, ok bool) {
> // same as above, but closing over numbers
> }
> }
>
> In any case - if you are unhappy with your pattern, there are many 
> alternatives to choose from, within the language as it exists today. It 
> seems hardly worth extra language features, to simplify this IMO rather 
> uncommon construct.
>
>
>
>> I've toyed with a few alternatives, but I'm having a hard time finding 
>> something I think everyone would like.
>>
>> Pattern the first; 'go return` which flips the idiom with syntactic 
>> sugar. 'go return' returns the function and continues the remainder of it 
>> in a go func() { ... }
>>
>> ```go
>> func getPositiveOdds(numbers []int) <-chan int {
>> channel := make(chan int)
>> go return channel
>>
>> defer close(channel)
>> for _, value := range numbers {
>> if value > 0 && (value & 1) == 1 {
>> channel <- value
>> }
>> }
>> }
>> ```
>>
>> The second more closely binds to the channel-generator pattern by 
>> extending make(chan) to take a 'go func' parameter:
>>
>> ```go
>> func getPositiveOdds(numbers []int) <-chan int {
>> generator := make(chan int, go func (channel chan int) {
>> defer close(channel)
>> for _, value := range numbers {
>> if value > 0 && (value & 1) == 1 {
>> channel <- value
>> }
>> }
>> })
>> return generator
>> }
>> ```
>>
>> I was tempted by the notion of having this auto-defer-close the channel, 
>> but I think retaining the explicit close is generally better and more 
>> teachable.
>>
>> Where it might be tenable would be using syntactic sugar to perhaps 
>> better promote the notion of generators toward 1st class citizens:
>>

[go-nuts] Better formatting of struct literals

[Eric Lindsey]

Recently, I gofmt'ed a block of code in a file and this is what I ended up 
with:

embed := {
Color: MembershipEmbedColor,
Description: "This collection is empty.\n" +
"Send an image or image URL to get started.",
Footer: {Text: "Membership"},
}

I would suggest that it would be more readable to format it thus:

embed := {
Color:   MembershipEmbedColor,
Description: "This collection is empty.\n" +
 "Send an image or image URL to get started.",
Footer:  {Text: "Membership"},
}

This would follow the style of formatting that gofmt uses for struct 
definitions. Aligning the second line of the continued string would be a 
special case; I personally haven't seen gofmt do that anywhere else, yet.

I hope this is the right place to file suggestions for gofmt. If not, 
please send me in the right direction.

Thanks,
Eric

-- 
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/b1980c2b-e67e-480f-bebb-92bd87f6d99en%40googlegroups.com.

Re: [go-nuts] Any embedded scripting language for Go

[Alejandro Sáez Morollón]

On 21/10/2020 07:31, Aravindhan K wrote:

Hi,

I am looking for a way to build interactive app,where user will be giving
instructions to draw as a script,rendering of the script will be displayed
live.
I would like to use below 2d drawing package for same,
github.com/fogleman/gg

Is there scripting language that would be able generate bindings to
arbiratory go packages back and forth? and I could embed it in Go App as
well.

Thanks,
Aravindhan K



Do you know Starlark? Not sure if it will suit you, but worth taking a 
look at it.


https://github.com/google/starlark-go

--
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/b180879d-3655-0130-6305-be8a81c5bc7c%40redhat.com.

[go-nuts] Using Golang to upload and download files in pcloud using cmd

[Bharath Baiju]

Hello all,

I am trying to use golang-pcloud  project 
to upload and download files.With this i can upload my files but 
downloading is not working.

Also when using this i can upload small size of files but when it is more 
than 50mb it is taking more time.

Is there any other method by using golang to connect to pcloud in cmd.Can 
anybody help me ?

Regards
Bharath baiju

-- 
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/4b65dd97-0636-4a31-893f-618181a9ac68n%40googlegroups.com.

Re: [go-nuts] Distributed go testing (running "go test" as a client)

[Craig Silverstein]

> You realize that the flag "-count 1" disable the cache, right?

Well, it disables *a* cache.  The docs don't make it clear, but it
seems like it only disables the test-cache.  I don't see why it would
affect the build caches -- build time being my theory as to why the
tests are slower.  But maybe it does?  Or maybe the extra time isn't
being spent in building after all.

> Also, why not using the "-p" flag if you want it to be parallel?

I should have done!

craig

On Mon, Oct 26, 2020 at 4:16 AM Shulhan  wrote:
>
>
>
> > On 26 Oct 2020, at 10.32, Craig Silverstein  
> > wrote:
> >
> > > But in my experimenting the overhead of calling `go test` is quite high: 
> > > `go test -count 1 ; go test -count 1 ` is 50% slower than `go 
> > > test -count1  `.
> >
> > Oops, I forgot to take parallelism into account.  Once I do, it drops to 
> > 30% slower (which is still significant):
> >
> > % time go test ./pkg/...
> > [...]
> > 97.100u 9.512s 0:34.22 311.5% 0+0k 31728+2640816io 79pf+0w
> >
> > % time sh -c 'find pkg -type d | parallel -iFOO go test -count 1 ./FOO'
> > [...]
> > 127.725u 18.722s 0:44.26 330.8%   0+0k 164592+2509424io 443pf+0w
> >
> > I'm curious why it's so much slower to run the tests one at a time than all 
> > at once.  What work is being redone? -- I'd think anything slow would have 
> > been cached.
> >
>
> You realize that the flag "-count 1" disable the cache, right?
>
> Also, why not using the "-p" flag if you want it to be parallel?

-- 
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/CAGXKyzFDzQizBGFCvFvtLXa7H6wDtqUKXuZTxfqr2vC2x5%2BOUw%40mail.gmail.com.

[go-nuts] Re: Windows "syscalls" and Go pointers

[Constantine Shablya]

Amending question above: is it ok for a function that takes pointer to a 
pointer
(so f(x *unsafe.Pointer) or f(**T)) to write a pointer (*x = 
unsafe.Pointer(...)
or *x = (*T)(...)) or should it store an uintptr (as in f(x *uintptr)) and 
that
uintptr then be cast to a pointer to appropriate type?


On Monday, October 26, 2020 at 4:23:13 AM UTC+2 Constantine Shablya wrote:

> Hello,
>
> I wish to call some Windows functions, some of which take pointers to types
> which themselves contain pointers. For this purpose I intended to use
> golang.org/x/sys/windows/mkwinsyscall.go and not cgo; in past I have 
> implemented
> a package that uses WASAPI by generating "syscall" bodies with 
> mkwinsyscall.go
> and doing syscall.SyscallN to call virtual functions in COM objects and so 
> have
> some prior experience.
>
> Now I want to call RegisterClassW which takes a pointer to WNDCLASSW as its
> parameter. One of the members of WNDCLASSW is lpszClassName of LPCWSTR type
> (UTF-16 string). This puzzled me as to how I should approach allocating 
> storage
> for that string? Taking into account Go specification making special
> reservations for pointers passed to cgo calls
> (https://golang.org/cmd/cgo/#hdr-Passing_pointers; my guess is that it is
> intended to facilitate possible implementations of moving garbage 
> collectors in
> future) I thought I would have to allocate storage with, say, C.malloc, 
> but that
> would require using cgo which so far I have not had to use. I looked into 
> how Go
> standard library handles this, and I found crypto/x509/root_windows.go
> checkChainSSLServerPolicy
> (
> https://github.com/golang/go/blob/fa98f46741f818913a8c11b877520a548715131f/src/crypto/x509/root_windows.go#L103
> )
> build a chain of pointers and then pass it to
> syscall.CertVerifyCertificateChainPolicy, which is in violation of the cgo
> passing pointers requirement. Although this particular case does not use 
> cgo, I
> believe pointer passing restriction would still apply to it.
>
> All of this made me puzzled, should I store a pointer returned by
> syscall.UTF16PtrFromString (golang.org/x/sys/windows.UTF16PtrFromString) 
> or use
> C.malloc+copy? Or, if the answer isn't straightforward, is it fair to 
> think that
> use of pointer returned by UTF16PtrFromString is more likely to break with 
> newer
> versions of go than C.malloc+copy or is it expected that there will be some
> amendments made to that function when a hypothetical moving GC 
> implementation
> lands?
>
>

-- 
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/8caad08a-d1ee-4757-8e56-cbe08772e80bn%40googlegroups.com.

Re: [go-nuts] Distributed go testing (running "go test" as a client)

[Shulhan]

> On 26 Oct 2020, at 10.32, Craig Silverstein  wrote:
> 
> > But in my experimenting the overhead of calling `go test` is quite high: 
> > `go test -count 1 ; go test -count 1 ` is 50% slower than `go 
> > test -count1  `.
> 
> Oops, I forgot to take parallelism into account.  Once I do, it drops to 30% 
> slower (which is still significant):
> 
> % time go test ./pkg/...
> [...]
> 97.100u 9.512s 0:34.22 311.5% 0+0k 31728+2640816io 79pf+0w
> 
> % time sh -c 'find pkg -type d | parallel -iFOO go test -count 1 ./FOO'
> [...]
> 127.725u 18.722s 0:44.26 330.8%   0+0k 164592+2509424io 443pf+0w
> 
> I'm curious why it's so much slower to run the tests one at a time than all 
> at once.  What work is being redone? -- I'd think anything slow would have 
> been cached.
> 

You realize that the flag "-count 1" disable the cache, right?

Also, why not using the "-p" flag if you want it to be parallel?

-- 
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/B3C847EA-DC0E-402B-B177-CEE22D9DF0C3%40gmail.com.

Re: [go-nuts] Should I always call runtime.LockOSThread() before calling C function?

[Jesper Louis Andersen]

On Sun, Oct 25, 2020 at 7:20 PM Tamás Gulácsi  wrote:

> I'd put all that C-calling code in ONE goroution, with
> runtime.LockOSThread, and send commands to this thread through a channel,
> with a receiver chan for response, too.
> This way only one goroutine needs LockOSThread, and only that pays the
> memory penalty.
> If it becomes the bottleneck, you can easily ramp up several such
> "C-facing-worker-goroutines".
>
>
I'd do this too.

If not for anything else, it is a good foundation from which to start. Once
you know more about the behavior of the system, you can try to lessen up
the constraints, but chances are you don't have to ever. It depends on the
use case.

-- 
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/CAGrdgiWo%3DZ%3D3wqcgMX_VFJK9yaHXr7nauYySJZpWaW%3DFF8%2BOgQ%40mail.gmail.com.

Re: [go-nuts] Re: SFTPGo gained Azure Blob Storage backend support

[Nicola Murino]

Il 26/10/20 01:38, ChrisLu ha scritto:
> Hi, Nicola,

Hi Chris,

>
> Great to see the SFTPGo author is also here! 
>
> Actually I was checking how to integrate FTP with SeaweedFS. It will
> be great to get some insight from you:
>
> 1) Really dumb question. Do people still use FTP? I have not used it
> myself for a long time.

I don't use it either, but surprisingly it seems a lot of people still
rely on it

> 2) How reliable/mature/performant
> is https://github.com/fclairamb/ftpserverlib ?

it is reliable and has good performance, almost the same as Pure/ProFTPD.

Some basic protocol functionality is still missing, but I think it's the
best FTP library available for Go.

regards,
Nicola

>
> Thanks!
>
> Chris
> ---
> https://github.com/chrislusf/seaweedfs
>
> On Sunday, October 25, 2020 at 2:01:11 PM UTC-7 Nicola Murino wrote:
>
> Hi,
>
> I just added Azure Blob Storage backend support to SFTPGo.
>
> If you are interested in this feature you are encouraged to try it
> out and report any issues you encounter.
>
> You can easily test the latest SFTPGo Git revision using the
> "edge" or "edge-alpine" tag for the Docker image or you can
> download the latest build artifacts (including deb/rpm) from the
> GitHub Actions page:
>
> https://github.com/drakkan/sftpgo/tree/master/docker
> https://github.com/drakkan/sftpgo/actions?query=workflow%3ACI
>
> Yours sincerely,
> 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/cec17f12-a6bd-4944-8198-9348d4d5e5can%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/d5c1106c-bc9e-0f71-1cc0-b205cd58452f%40gmail.com.