Re: [go-nuts] Re: Range over int

[Amnon]

So in 2012 Cyril Oblikov wrote

Why isn't this code correct?

var N int = ...
for i := range N {
doSmth(i)
}

In my opinion it looks much simpler than:

var N int = ...
for i := 0; i < N; i++ {
doSmth(i)
}

So we should say to Cyril (whether he is today), that it is now correct.
You just needed to wait around for a 12 years.
Because you were just ahead of your time

And if you are reading these lines, please post again to give us a glimpse 
of what new features we should expect to be added to Go in 2036...

- amnon

On Saturday 24 February 2024 at 01:20:04 UTC Duncan Harris wrote:

> I made some changes to use range over int in our code base and was 
> pleasantly surprised with the improvement in readability.
>
> We had quite a few instances where the number of iterations involved a 
> function call which we don't want to repeat:
>
> - for i, n := 0, f(); i < n; i++ {
> + for i := range f() {
>
> A surprising amount where we no longer need the range variable including 
> some nested loops:
>
> - for repeat := 0; repeat < col.Repeat; repeat++ {
> -  for j := 0; j < len(cats); j++ {
> -  for k := 0; k < numStats; k++ {
> + for range col.Repeat {
> +  for range len(cats) {
> +  for k := range numStats {
>
> There were also all the benchmarks:
>
> - for n := 0; n < b.N; n++ {
> + for range b.N {
>
> We could update the docs in https://pkg.go.dev/testing accordingly :-)
>
>
> On Friday 23 February 2024 at 06:18:33 UTC Henry wrote:
>
> This is one feature that provides little value beyond saving a few 
> keystrokes and looking slightly nice, but with potential of increased 
> complexity when we need to implement more important features to the 
> language down the road. This is my opinion. It shouldn't have been added, 
> but what was done is done. There is nothing we can do about it now. 
>
> On Sunday, February 18, 2024 at 5:38:25 AM UTC+7 poweredb...@gmail.com 
> wrote:
>
> I agree with you.
>
>
> Powered By Citizen 
>
> On Saturday, February 17, 2024, 1:19 AM, Kurtis Rader <
> kra...@skepticism.us> wrote:
>
> It's not just changing `k` inside the loop body that makes the 
> transformation invalid -- your observation also applies to modifying `i` 
> inside the loop body. Modifying either variable inside the loop body is 
> extremely rare in my experience and doing so warrants a "dragons be here" 
> comment. Still, your point is valid and anyone applying such a 
> transformation should carefully evaluate the body of each loop to see if 
> either variable might be modified by the loop body. Obviously it would be 
> nice if a tool automated that analysis and transformation but I'm not going 
> to hold my breath waiting for someone to implement that tool.
>
> On Fri, Feb 16, 2024 at 11:06 PM Patrick Smith  wrote:
>
> On Fri, Feb 16, 2024 at 10:27 PM Amnon  wrote:
>
> But now it is out, I think it is great, and have run 
> perl -pi -e 's/for (\w+) := 0; \1 < ([\w()]+); \1\+\+/for \1 := range 
> \2/' $(git grep -l for) over my entire codebase to use it everywhere.
>
>
> You know your own codebase, and maybe this was safe for you to do. But in 
> general, blindly applying such a blanket change has the potential to cause 
> bugs, as these two are not always equivalent:
>
> for i := range k
> for i := 0; i < k; i++ 
>
> In particular, if k is changed inside the loop they may be very different. 
> https://go.dev/play/p/kAHcmu7377I
>
> (Yes, many people, myself included, would consider changing k inside such 
> a loop to be bad coding style. But "bad style" doesn't mean it's not going 
> to be done.)
>
> -- 
> 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/CAADvV_trGNxeLUma722wk-JOGnz42fJqM8%3DVZ36TKpr5s-%3DmOQ%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/CAADvV_trGNxeLUma722wk-JOGnz42fJqM8%3DVZ36TKpr5s-%3DmOQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>
> -- 
> 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/CABx2%3DD9Hyjj_N9KjY6XfFH0ZUt55f27VCcZQSj_DyX36gzrX1g%40mail.gmail.com
>  
>

Re: [go-nuts] heap pprof profile showing only 10Gi out of 50Gi of actually used memory

[Amnon]

Worth studying https://tip.golang.org/doc/gc-guide
The heap profile will show you the heap memory in use, 
but the OS process info will tell you the total process size, including 
memory in use,
and memory GC which has been marked as free and reclaimed by the GC, but 
not relinquished to the OS.
When the GC frees memory, it often does not return it to the OS, but keeps 
it around because it might be needed soon.
You can only return entire pages to the OS, so the GC often can't return a 
memory page even if most of it is free,
but a small part of it is still in use.

On Wednesday 21 February 2024 at 18:43:00 UTC Frank Flipper wrote:

> it's a purely golang app
> On Tuesday, February 20, 2024 at 9:38:35 PM UTC+3 Kurtis Rader wrote:
>
>> Is your app built with CGO? That is, do you link it against any C/C++ 
>> code that might be calling malloc?
>>
>> On Tue, Feb 20, 2024 at 5:22 AM Frank Flipper  
>> wrote:
>>
>>> I have an app that's put inside k8s container and is being monitored in 
>>> grafana. Memory usage graph shows me that one of the pods is using 50Gi of 
>>> memory, but when I go to /debug/pprof/heap I only see that it's 
>>> using only 10-11Gi. I'm aware that pprof is not meant to track and show 
>>> every single allocation, but I'm bothered by difference in 40Gi.  
>>>
>>> -- 
>>> 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/8eb463f6-e608-40b0-8df5-c497e2a1414an%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>

-- 
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/333dfdbb-876b-4c3c-a953-a97256bf6d0bn%40googlegroups.com.

Re: [go-nuts] Re: Range over int

[Amnon]

Indeed. The thread started 12 years ago. At the time I thought the idea of 
ranging over an int was just dumb, and un-go-like.
But now it is out, I think it is great, and have run 
perl -pi -e 's/for (\w+) := 0; \1 < ([\w()]+); \1\+\+/for \1 := range 
\2/' $(git grep -l for) over my entire codebase to use it everywhere.

On Friday 16 February 2024 at 01:38:55 UTC Jorge Massih wrote:

> Hey folks! Now in in Go v1.22 (released 02-06-2024) 
>  it's possible to iterate over a range 
> of integers by doing the approach mentioned at the beginning of this 
> conversation.
>
> - JM
> El miércoles, 7 de enero de 2015 a la(s) 9:42:07 p.m. UTC-4, Sean Russell 
> escribió:
>
>> On Wednesday, January 7, 2015 11:51:03 AM UTC-5, tomwilde wrote:
>>>
>>> ... 
>>>
>> Having introduced this convenience range-syntax where you can specify the 
>>> upper bound; wouldn't it by extension make sense to also allow the 
>>> programmer to specify a lower bound à la "x := range a, b".
>>>
>>> And from there people will want list comprehensions, texas ranges, etc, 
>>> etc...
>>>
>>> It's a slippery slope.
>>>
>>
>> There are already people who want list comprehension; you don't need 
>> range syntax changes as a gateway feature for that.
>>
>> --- SER 
>>
>

-- 
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/197f8c57-c78e-48c8-b08a-761ab570189dn%40googlegroups.com.

[go-nuts] remove pre-1.22 cruft

[Amnon]

Now that 1.22 is out, is there an easy way to remove pre-1.22 cruft,
like 

x := x 

assignments inside loops.

-- 
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/4a9dcc52-eee5-49ad-9a11-076178f44f57n%40googlegroups.com.

[go-nuts] Go 1.22 code simplification

[Amnon]

Go 1.22 contains some cool features which will allow us to write simpler 
code.

Would it be possible for gofmt -s to help us do transformations which clean 
up old code such as 
for i := 0; i < n; i++   -> for i := range n
removing x := x assignments inside range loops
or updating code to use the new math/rand/v2 API?

If not, has anyone written any refactoring tools to do this?


-- 
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/91a531a9-5043-4357-b643-d1600dcae119n%40googlegroups.com.

Re: [go-nuts] Re: does anyone have an example of a Go kernel module

[Amnon]

Why would you want to do that? The amount of stuff going on under the hood 
in a Go program (GC, scheduling, etc)
make it a bad fit for low level kernel stuff. 

So best stick to C.
Writing a Kernel module in C is well supported and documented.
Having a skim through https://lwn.net/Kernel/LDD3/ .

Recently some people have been writing modules in Rust.
I have not tried it myself, but there is some documentation on the web, eg 
https://www.kernel.org/doc/html/latest/rust/quick-start.html

Or as others have suggested write your program as a plain old user-mode 
program in Go,
and write a minimal device driver which creates a sys-fs device tree that 
your program can talk to.

On Monday 8 January 2024 at 02:20:00 UTC Robert Engels wrote:

> Hasn’t been touched in 6 years and it doesn’t work. I guess they figured 
> out it wasn’t worth the effort. 
>
> The only plausible way to write a kernel module in Go is… don’t.
>
> Maybe run a user space Go process and some sort of shared memory 
> communication. 
>
> On Jan 7, 2024, at 8:06 PM, Hữu Hà  wrote:
>
> 
>
> Maybe you mean something like this ?
>
> https://github.com/gopher-os/gopher-os
>
> Vào lúc 04:22:10 UTC+7 ngày Chủ Nhật, 7 tháng 1, 2024, Siglo XIX đã viết:
>
>> I have tried many ways but now that the ecosystem is more mature maybe 
>> someone knows of an example of how to make a Linux kernle module with 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...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/cf1a03df-6782-4ef7-92af-4d3f3dc833c8n%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/a9f359be-38bb-43ca-bab5-fb41fe59aea7n%40googlegroups.com.

[go-nuts] Re: [ANN] go-zeromq/zmq4: pure-Go implementation of ZeroMQ

[Amnon]

Apologies for reopening an ancient thread. 
But what was the motivation for re-implementing zeroMQ in Go?

I am asking because my company is proposing to add zeroMQ support to our 
code 
using a CGO wrapper for libzmq. (Currently our product is pure Go).
What problems would should we expect if we decide to go down the CGO route?

- Amnon

On Thursday, 14 June 2018 at 08:30:39 UTC+1 Sokolov Yura wrote:

> Great! It is really long waited. 

-- 
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/8963f03a-f7f9-45e2-b235-ccce0be865d3n%40googlegroups.com.

Re: [go-nuts] Best IDE for GO ?

[Amnon]

IDE is indeed a personal choice.
The Go developer survey often asks which IDE people use.
Last year, the favourite was VS code with 45% of users, followed by Goland 
with 34%.

On Sunday, 20 August 2023 at 17:38:26 UTC+1 burak serdar wrote:

> On Sun, Aug 20, 2023 at 1:52 AM TheDiveO  wrote:
>
>> well, our "(major) engineering orgs" leave the choice of IDE to our devs. 
>> Devs have different styles, so as long as they meed the demand, who cares.
>>
>
> I second that. IDE is a personal choice. For years, I've been using Emacs 
> to edit code, and that's what I still feel most comfortable with for most 
> development tasks. When I need to debug something, I use VSCode, but I find 
> editing code using VSCode very disturbing.
>
> That said, based on the experience I have mentoring other developers using 
> IDEs, I agree with the viewpoint that IDEs promote productivity, but with 
> superficial knowledge. If you do not take the time to learn how certain 
> things work, the code you write may not be correct. Many questions on Stack 
> Overflow are simply answered by pointers to API docs, but people don't read 
> them because of code completion and code suggestion features of the IDEs.
>  
>
>>
>> On Saturday, August 19, 2023 at 11:17:35 PM UTC+2 Robert Engels wrote:
>>
>>> Reread what I wrote. Vim with autocomplete, etc is not a simple text 
>>> editor with syntax coloring. 
>>>
>>> Still every major software engineering org in the world uses an ide (or 
>>> multiple). I guess they don’t know what they are doing. 
>>>
>>> Btw, Googles current IDE is based on VSCode. 
>>>
>>> > On Aug 19, 2023, at 3:24 PM, Jan Mercl <0xj...@gmail.com> wrote: 
>>> > 
>>> > On Sat, Aug 19, 2023 at 10:06 PM Christian Stewart 
>>> >  wrote: 
>>> > 
>>> >> Autocomplete and a go language server (gopls) add a ton of speed 
>>> because you don't need to look up the docs for function and variable names. 
>>> And go to definition improves speed navigating code significantly. 
>>> > 
>>> > - Using autocomplete and go-to-definiton does not require VSCode or 
>>> > any other IDE. 
>>> > - I do use autocomplete and go-to-definition. When I said I use no 
>>> > IDE, that does not mean I don't use those features. 
>>> > - The speed of typing/inputting code is overally a rather negligible 
>>> > factor of the total time cost of developing/debugging and maintaining 
>>> > any non-toy project. IOW, it's not a significant metric of 
>>> > productivity. 
>>> > 
>>> >> But vim-go can do both, so why not just use it? 
>>> > 
>>> > Because I use govim? ;-) 
>>> > 
>>> > (But not for my large projects, gopls chokes on them still too often 
>>> > to tolerate it.) 
>>> > 
>>> > -- 
>>> > 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/CAA40n-XusymW6gb5OnDa_7QWAWPFSkwKYQMYUm-d7419EZ%2BGkQ%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...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/8d5b52de-ddee-461a-9ed5-9b0968382d17n%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/b89f6d0b-6da0-44b7-a33b-ff83bf8995dan%40googlegroups.com.

Re: [go-nuts] I need confirmation about whether I'm in front of a linter false positive.

[Amnon]

I would stop using that particular linter.

And keep calling your error value err. 
It is idiomatic.

On Monday, 14 August 2023 at 22:36:11 UTC+1 David Finkel wrote:

> On Mon, Aug 14, 2023 at 4:54 PM Pablo Caballero  wrote:
>
>> I started working on a Golang project (from my work). The following 
>> pattern makes the company configured linter to complain with:
>> sloppyReassign: re-assignment to `err` can be replaced with `err := 
>> myFunc2()` (gocritic)
>>
>> func myFunc() error {
>> ...
>> blah, err := getBlah()
>> if err != nil {
>> return err
>> }
>> ...
>> if err = myFunc2; err != nil {
>> return err
>> }
>> ...
>> }
>>
>> What bothers me the most is the fact that if I listen to the linter and 
>> change the code according to its suggestion I get another complaint saying 
>> that I should use the if short version.
>>
>> Yes, I have found silenced sloppyReassign following this pattern.
>>
>> What do you think? What linter complaint should I mute? I don't like the 
>> idea of a code base polluted with instructions to tell the linter to shut 
>> up. Do you think I should suggest stopping using linters? :)
>>
> My recommendation is to stop re-using the "err" variable.
> I eliminated missed if err != nil checks in my codebases by using unique 
> names for my error-typed variables. (and reserving the "err" itself for 
> innermost scopes -- short if statements like the second case you have there)
>  
>
>>
>> Thank you!
>>
>> -- 
>> 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/CAPxFe-utkjMEVrc3DtTR5rmsiEuK8ZLvA6d228PjnroaxRtBkw%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/a93d303c-19f9-4353-96c1-b7720e66a444n%40googlegroups.com.

Re: [go-nuts] Please consider voting to reopen Golang subreddit

[Amnon]

Sorry, but I have been away and missed the context.

What is the protest about?

What has redit changed?

Thanks

On Saturday, 24 June 2023 at 06:07:38 UTC+1 Axel Wagner wrote:

> On Sat, Jun 24, 2023 at 3:03 AM cpa...@gmail.com  wrote:
>
>> If 100 people are on a boat and 51 want to sink the boat is that fair to 
>> the 49 who want to live?
>
>
> This is not a life-or-death situation and such comparisons are almost 
> universally unhelpful, as you literally do not have a choice in them.
>
> You’re taking a resource away from others.  
>>
>> If someone wants to protest Walmart they don’t burn it down. 
>>
>
> No one is burning down anything. But, again, protest has to be 
> inconvenient. And contrary to the claims made by you and Jan, yes, it is 
> actually completely normal (and legal, in most legislatures) for a protest 
> to temporarily "take resources away from others". Roads get closed for 
> protest marches all the time.
>
> But really, what I miss most here is an argument about the actual subject 
> matter. If you are frustrated about the subreddit being closed, you can 
> direct that frustration at the moderators or you can direct it at Reddit. 
> If they didn't implement their API changes, the protest would end, after 
> all.
>
> You seem to be taking it as a given that the moderators are the 
> appropriate target of the frustration and that they should be automatically 
> the one to give in. When Jan asked me - an unrelated party - to refund his 
> Reddit fee, he could've just as well written to Reddit, telling them that 
> he wants his money back because their insistence on overcharging for their 
> API causes this protest and makes reddit less valuable to him. That 
> would've likely done exactly as much to get his money back. But it would 
> actually exert pressure on someone who has a hand in this issue - after 
> all, threatening Reddit's bottom line is what this protest is all about. 
> And given that his business relationship is with Reddit, that's the only 
> party he actually has any real leverage with. So I'm really confused that 
> someone would bend over backwards, logically speaking, to misdirect their 
> frustration this way.
>
> If you want to convince me, at least, that the protest is bad, you have to 
> convince me that the API charges Reddit is implementing are good and 
> justified and that the moderators are wrong to object to them. You won't 
> convince me with arguments about the procedure.
>
> Or to put it another way: In your metaphor, you are assuming that the 
> moderators protesting are the ones who are trying to sink the boat. I'm not 
> convinced of that. To me, they make a pretty convincing case that it's 
> their actions which are trying to keep the boat afloat, by preserving 
> third-party tools that are essential to reddit's operation and the 
> voluntary labor of the moderators. And if the owner of a ship directs it to 
> steer into an iceberg and the crew objects, I'd expect the passengers to 
> back them in it, instead of complaining that they'll be late and how dare 
> they obstruct *my* right to have the ship go wherever I want.
>
> Anyways… as I said, this isn't actually such a dramatic situation. It's 
> just a website being closed for a bit. And if the mods are open to a vote 
> on whether or not to participate in the protest, that seems a perfectly 
> serviceable process to me. People should feel free to vote on that poll 
> however they like. I just wanted to provide some counterweight to the 
> initial call to vote against the protest.
>  
>
>>
>> On Friday, June 23, 2023 at 4:37:20 AM UTC-4 Axel Wagner wrote:
>>
>>> On Fri, Jun 23, 2023 at 10:29 AM Jan Mercl <0xj...@gmail.com> wrote:
>>>
 On Fri, Jun 23, 2023 at 10:18 AM Axel Wagner
  wrote:

 > Just for context, as not everyone seems to be aware: I was, in that 
 sentence you quoted, referring to examples like this
 > 
 https://www.reddit.com/r/ModCoord/comments/14eq8ip/the_entire_rmildlyinteresting_mod_team_has_just/
 > This demonstrates that even with overwhelming support from the 
 community (and yes, in this example the modifier applies), the company 
 overwrites those wishes to shut down protest. There are a couple of other 
 subreddits with similar stories.
 >
 > So I was making the case to *provide* overwhelming support for the 
 mods of /r/golang, referring to precedent of other subreddits where that 
 is 
 happening. Not claiming that they already have it.

 Thanks for the added conext.

 Anyone not liking Reddit is free to not visit the site. Anyone not
 accepting the price for the API access is free to not buy it. It's
 fine to vote by your visits and by your wallet. That's how the free
 market works and it works well unless there's some monopoly. But
 Reddit has no monopoly.

 Protesters are free to protest. That's their respected right.
 Protesters have no right to deny access to 

Re: [go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows

[Amnon]

Someone should publish a benchmark of compiling Go code on Windows, Linux, 
osX.
People can take this into account when selecting their development platform.
And if enough people complain about Windows machines being several orders 
of magnitude slower 
than similar priced competing platforms, then maybe Microsoft will take 
note and fix their Anti-Virus tools.

On Thursday, 22 June 2023 at 13:47:59 UTC+1 Jet Li wrote:

> Like to note that if you mean Windows Defender, there is no way to disable 
> that after Build 20H2 iirc where I was task to deploy Windows 10 and could 
> not find the option in Windows Group Policy settings after the update, if 
> Go app are affected by Windows Defender. Your only option is to use older 
> Windows build and alternative OS, mileage may vary.
>
> Another option, could be impossible to backup VM image as it's on macOS
> https://multipass.run/
> On Thursday, 22 June 2023 at 19:52:56 UTC+8 Wojciech S. Czarnecki wrote:
>
>> Dnia 2023-06-18, o godz. 22:52:58 
>> tokintmash  napisał(a): 
>>
>> > Hello, 
>> > 
>> > Was there a solution to this? I am having the same issue. Win 10 
>> machine 
>> > and compiling and running simple lines of code takes ages. 
>>
>> The answer is always the same: turn off your antivirus software for your 
>> development tree. 
>>
>> Such delays are due to "heuristics" usually implemented by uploading your 
>> exe to the vendor. 
>> Root cause is that after 12 years AV vendors still can not cope with what 
>> they pereceive 
>> a "non standard" linker, ie. a Go's one. 
>>
>> hope this helps, 
>>
>> -- 
>> Wojciech S. Czarnecki 
>> << ^oo^ >> OHIR-RIPE 
>>
>

-- 
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/ec1b0a6c-0bf1-4d7a-ab77-2c2daeffb58dn%40googlegroups.com.

Re: [go-nuts] Re: Home directory?

[Amnon]

Ok Jan, you are right. They do still play a part under the hood.
So external modules get cached under $GOMODCACHE which is $GOPATH/pkg/mod 
by default
and go install installs executables under $GOBIN which is $GOPATH/bin by 
default.

But my point is that (apart from $GOBIN), this is something that the 
end-user no longer needs to bother themselves with.
Unlike the earliest go versions, you no longer need to set GOPATH in order 
to compile your code.
And you no longer need to insert your code into a directory tree under 
GOPATH. 

On Sunday, 23 April 2023 at 09:49:40 UTC+1 Jan Mercl wrote:

> On Sun, Apr 23, 2023 at 10:28 AM Amnon  wrote:
>
> > Yes GOPATH and GOROOT have been deprecated.
>
> Both are alive and well. They are essential for the build system/go
> command to work as required.
>
> tl;dr: There's a default value of GOPATH so one does not have to set
> it. A much longer version can be obtained by '$ go help gopath'.
>

-- 
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/de5284b3-2a85-4870-9229-51db75f062ffn%40googlegroups.com.

[go-nuts] Re: Home directory?

[Amnon]

I looked at https://go.dev/doc/tutorial/create-module 
it only has two mentions of, which are just suggestions regarding where to 
create your working directory.
But it is just a suggestion, and you can choose any location which is 
convenient for you. 

Yes GOPATH and GOROOT have been deprecated. Any tutorials which tell you to 
put your code under $GOPATH are ancient history
and should be ignored. 

On Sunday, 23 April 2023 at 09:16:59 UTC+1 joseph.p...@gmail.com wrote:

> In the ‘Create a Go Module’ documentation, it keeps referencing ‘home 
> directory’ and uses the unix command ‘cd’.
>
> Do they literally mean my unix home directory or do they mean my GOPATH 
> directory?
>
> Have GOPATH and GOROOT been deprecated?
>
> Thanks,
>
> Hoe
>

-- 
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/ac730909-ba56-49d9-86a7-a743d5a801f5n%40googlegroups.com.

Re: [go-nuts] Redfining loop variable semantics - what's the plan?

[Amnon]

Thanks for a very succinct response.

So if I understand the CL, there will be no change in behaviour in 1.21, 
unless you set GOEXPERIMENT=loopvar

- Amnon



On Saturday, 25 March 2023 at 06:56:23 UTC Sean Liao wrote:

> https://go.dev/issue/57969
>
> - sean
>
> On Sat, Mar 25, 2023, 06:45 Amnon  wrote:
>
>> Hi Gophers,
>> Last year there was a discussion about removing one of the 
>> more common gotchas in Go.
>>
>> To quote from the discussion:
>>
>> the problem is that loops like this one don’t do what they look like they 
>> do:
>>
>> var all []*Item
>> for _, item := range items { all = append(all, ) } 
>>
>> That is, this code has a bug. After this loop executes, all contains 
>> len(items) identical pointers, each pointing at the same Item, holding 
>> the last value iterated over. This happens because the item variable is 
>> per-loop, not per-iteration:  is the same on every iteration, and 
>> item is overwritten on each iteration. 
>> https://github.com/golang/go/discussions/56010
>>
>> What was the resolution of this discussion?
>> Was the proposed change accepted?
>> Will it be released in Go 1.21 or 1.22?
>>
>> It is hard to figure this out from the discussion. There are hundreds of 
>> comments,
>> but there is no clear marking of the resolution (apart from the 
>> discussion now being closed) either at the top of bottom of the discussion.
>>
>>
>> -- 
>> 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/5d88208e-fbbf-44d5-b693-50deff176fedn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/5d88208e-fbbf-44d5-b693-50deff176fedn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
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/aba5e0bd-c676-45f0-a7b7-ce6e23985124n%40googlegroups.com.

[go-nuts] Redfining loop variable semantics - what's the plan?

[Amnon]

Hi Gophers,
Last year there was a discussion about removing one of the 
more common gotchas in Go.

To quote from the discussion:

the problem is that loops like this one don’t do what they look like they 
do:

var all []*Item
for _, item := range items { all = append(all, ) } 

That is, this code has a bug. After this loop executes, all contains 
len(items) identical pointers, each pointing at the same Item, holding the 
last value iterated over. This happens because the item variable is 
per-loop, not per-iteration:  is the same on every iteration, and item is 
overwritten on each iteration. 
https://github.com/golang/go/discussions/56010

What was the resolution of this discussion?
Was the proposed change accepted?
Will it be released in Go 1.21 or 1.22?

It is hard to figure this out from the discussion. There are hundreds of 
comments,
but there is no clear marking of the resolution (apart from the discussion 
now being closed) either at the top of bottom of the discussion.


-- 
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/5d88208e-fbbf-44d5-b693-50deff176fedn%40googlegroups.com.

Re: [go-nuts] HTTP client - streaming POST body?

[Amnon]

As Bruno said.

Try something like this:

func uploadBig(url string ) error {
file, err := os.Open("bigfile.txt")
if err != nil {
return err
}
defer file.Close()
resp, err := http.Post(url, "text/plain", file)
if err != nil {
return err
}
defer resp.Body.Close()
if resp.StatusCode >= 400 {
return fmt.Errorf("Bad Status %s", resp.Status)
}
_, err = io.Copy(os.Stdout, resp.Body)
return err
}


On Monday, 6 March 2023 at 15:17:36 UTC Bruno Albuquerque wrote:

The body is just an io.Reader. You just need to write one that materializes 
and streams the data you want instead of using a buffer with all of it. The 
entire design is to allow things like what you want to do. :)

-Bruno


On Mon, Mar 6, 2023 at 10:08 AM 'Jim Smart' via golang-nuts <
golan...@googlegroups.com> wrote:

Hi all,

I'm looking for an HTTP client that allows my code to write the body 
content down the pipe while doing a POST.

The use case here is that I'm wishing to send very large UPDATE/INSERT 
queries/commands to an HTTP endpoint, and the body content of those 
queries/commands is actually generated from a database. So it would be 
better, memory- and performance- wise, if I could write that straight down 
the pipe during the request, as opposed to manifesting the whole of the 
query/command into a buffer before doing the POST.

Is this possible at all with the stdlib http.Client? Perhaps with an 
io.Pipe as the request body?

I did look at the code for http.Client a little, but there's a lot of it, 
and it's not the simplest of code to follow. I do have a base understanding 
of the HTTP 1.1 protocol, but there's a lot more to http.Client than just 
that, of course.

I've also tried looking for existing examples showing similar 
functionality, but did not seem to find anything. Which is partly what 
makes me wonder if perhaps the stdlib http.Client cannot operate like this.

If I can't do this with the stdlib http.Client, and I have to roll-my-own 
client of sorts, are there any parts of the existing http package that I 
should be making use of?

Any tips / pointers / info greatly appreciated.

Thanks,
/Jim

-- 
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/545d0597-66a0-4412-8ca7-3d447f88ccafn%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/d9e4e00f-2251-453c-88f2-5e2bb8e61c8bn%40googlegroups.com.

[go-nuts] Re: Reading .xls file with golang

[Amnon]

File an issue at https://github.com/extrame/xls/issues
and maybe submit a fix?

On Wednesday, 15 February 2023 at 03:22:30 UTC Aadi Sharma wrote:

> While reading .xls file with golang using  *ReadAllCells *function  from 
> xls package 
> https://github.com/extrame/xls/blob/v0.0.1/workbook.go#L268
>
> Issue - For strings it works fine , but for the cell having int value 
> get's changed to date format. 
> ex:- (*1* get changed to *1900-01-01T00:00:00Z*)
>
> How we will deal with this ?
>

-- 
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/e2779117-14fa-4a90-93da-02004fb71ff6n%40googlegroups.com.

Re: [go-nuts] Linting

[Amnon]

> But perhaps I'm just a sucker for quality and maintainability and I'm 
barking up the wrong tree.

I don't think that you will find many people here who don't think that code 
quality and maintainability 
are important.

But I would disagree with the implicit assumptions that
code that "passes" a linter is of high quality
and that code that "fails" the linter is of poor quality

>From my limited readings of the Go source code, I would say that the Go 
team's judgement of code quality is far beyond that
of any linter I have seen. 

On Wednesday, 14 December 2022 at 23:07:24 UTC marc...@gmail.com wrote:

>
>
> Sorry, but I didn't state (and so does the linter) that any code is 
> deficient.
> Normal usage of a linter is not to satisfy a linter, but to do some basic 
> code review.
> (Most new linters can skip certain code lines these days too.)
>
> I know that  the number of lines in a single function is just a matter of 
> taste.
> But I also know that a function with too many lines is also harder to 
> maintain.
> If you study those functions that are "too long", you will find that it 
> could probably be split up in a more readable and maintainable way.
>
> The only worry I have is that complex code is very hard to maintain, 
> perhaps only by a single person.
> What happens if that person isn't available anymore? The best time to 
> maintain code to  a more maintainable version, is at the moment of creation 
> or not much later,
> because only then it lives still "in the mind" of the creator. A linter 
> can help detect those "blindspots" of a developer and can point out where 
> those are.
>
> With the new guidelines, one can expect to see the Go code as an example 
> of those guidelines.
> (one of them being maintainable software)
>
> Does anybody have to fix all of it now? Of course not, but perhaps when a 
> developer is touching one of those functions and understands what it does, 
> then it is still the ideal time to rewrite it a bit.
>
> But perhaps I'm just a sucker for quality and maintainability and I'm 
> barking up the wrong tree.
> I very much want Go to survive, so for me that means that people should 
> not be afraid to maintain parts of the code.
> (and that's why I said not to touch all those high complexity parts, 
> because I find it highly confusing; so i'm not fit for that job.)
>
> Op wo 14 dec. 2022 om 23:33 schreef Amnon :
>
>> This long discussion started with the question why the Go source is not 
>> linted. 
>> But I think the OP has answered his own question by providing us with a 
>> list of 963 places 
>> where the linter has decided that the code is deficient. 
>> But what is notable, is that he has not given a single example where any 
>> of these 963 warning has any value.
>> He has not taken even one of these warnings and show how "fixing" it 
>> leads to better code.
>> 411 of these warnings are for functions which are longer than the 150 
>> lines which are "allowed".
>> So I would ask: "allowed by whom?"
>> I am a big fan of short functions, as are the authors of the Go standard 
>> library. But surely the optimal length of a function depends
>> on the context. I am not too bothered, about the length of functions in 
>> the output of code generation, for instance. And I am OK with 
>> code with a very regular structure - like a switch statement handling 
>> many cases to take many lines.
>> Some of these linters do seem to be quite bureaucratic - imposing 
>> arbitrary rules irrespective of whether they make sense in the actual 
>> context.
>> Code written in corporations (because it usually is in corporations) 
>> where these linters are imposed, have a particular smell, with all kinds
>> of convolutions and ugliness designed to appease the linter.
>> If you see code where every line begins with 
>>
>> _, _ =
>>
>> Or where you always see 
>>
>> defer func() { _ = res.Body.Close())() 
>>
>> rather that 
>>
>>defer res.Body.Close()
>>
>> you know that this is the product of a programmer toiling under the 
>> dictates of a linter.
>> Because if you are discussing some code with a knowledgeable reviewer, 
>> you can defend your decisions.
>> You can explain why writing to a byte.Buffer can not fail (unless we are 
>> out of memory, in which case any error 
>> handling will fail too). But if you are told off by a linter, there is no 
>> appeal. The linter has no discretion.
>> It is not open to discussion. It will not consider your arguments. Your 
>> job is to do what the lin

Re: [go-nuts] Linting

[Amnon]

This long discussion started with the question why the Go source is not 
linted. 
But I think the OP has answered his own question by providing us with a 
list of 963 places 
where the linter has decided that the code is deficient. 
But what is notable, is that he has not given a single example where any of 
these 963 warning has any value.
He has not taken even one of these warnings and show how "fixing" it leads 
to better code.
411 of these warnings are for functions which are longer than the 150 lines 
which are "allowed".
So I would ask: "allowed by whom?"
I am a big fan of short functions, as are the authors of the Go standard 
library. But surely the optimal length of a function depends
on the context. I am not too bothered, about the length of functions in the 
output of code generation, for instance. And I am OK with 
code with a very regular structure - like a switch statement handling many 
cases to take many lines.
Some of these linters do seem to be quite bureaucratic - imposing arbitrary 
rules irrespective of whether they make sense in the actual context.
Code written in corporations (because it usually is in corporations) where 
these linters are imposed, have a particular smell, with all kinds
of convolutions and ugliness designed to appease the linter.
If you see code where every line begins with 

_, _ =

Or where you always see 

defer func() { _ = res.Body.Close())() 

rather that 

   defer res.Body.Close()

you know that this is the product of a programmer toiling under the 
dictates of a linter.
Because if you are discussing some code with a knowledgeable reviewer, you 
can defend your decisions.
You can explain why writing to a byte.Buffer can not fail (unless we are 
out of memory, in which case any error 
handling will fail too). But if you are told off by a linter, there is no 
appeal. The linter has no discretion.
It is not open to discussion. It will not consider your arguments. Your job 
is to do what the linter tells you. 
Because the linter is always right. Because the computer is always right. 
And you, as a mere human, are always wrong.

I would say that go vet is an exception - its warnings almost always point 
to real problems in the correctness of code,
or unnecessary complexity. I often also run staticcheck on my own code. It 
often makes useful observations, some of which 
lead to useful changes. But beyond these two, linters often do more harm 
than good. One very high quality linter with 
few false positives is far more valuable that a large number of linters 
which make nonsensical complaints.
golangci_lint is particularly bad in this respect - making it easy to run 
loads of low quality linters, which cry wolf all the time and 
train programmers to ignore warnings.

So I would appeal Ian and the rest of the Go team, to resist the pressure 
to adopt these "great linters" - not to invest months of work
"fixing" these 963 "problems" identified by these linters. And focus on 
carrying on doing what you are doing - producing,
rocks solid releases, well thought out enhancements, and code which can 
serve as a template we can all emulate
to produce good, clear, idiomatic code. 


On Tuesday, 13 December 2022 at 22:18:14 UTC marc...@gmail.com wrote:

> I have no complaints, let me be clear about that. Just advice, for all 
> I've learned in my cariere is that maintenance is happening more than the 
> first version of something creative.
> But I've still got hope that one day I might understand some complex 
> coding that I didn't write myself.
>
> I'm happy to help, if an author of something "complex" can guide me. The 
> only thing I can do now, is be a messenger.
>
>
> Op di 13 dec. 2022 om 20:52 schreef Ian Lance Taylor :
>
>> On Tue, Dec 13, 2022 at 2:31 AM Brian Candler  wrote:
>> >
>> > With that in mind, I'd respectfully suggest that your starting point 
>> should be to pick one of these "over complex" functions, understand it 
>> fully, and rewrite it in what you consider to be a simpler/clearer way 
>> which does not break any functionality, *and* which does perform any worse 
>> than the original code (*).  Then you can submit it as a pull request for 
>> review.  Rinse and repeat.
>>
>> With respect, I'm going to suggest not doing that.  If code is working
>> correctly, then changing it, even to simplify it, may cause it to stop
>> working correctly.  In fact, this is more likely to happen if the
>> original code is complex.  The best approach to complex working code
>> is to only change it if there is a good reason to do so: because the
>> requirements have changed, or because there is some way to make it run
>> measurably faster, or because it is a regular source of bugs.
>>
>> Also I hope we can all agree that blind adherence to any specific
>> definition of complexity is misguided.  For example, a function that
>> is basically a big switch statement with a bunch of cases is often
>> easier to understand as a single function rather than a 

Re: [go-nuts] Which websockets implementation

[Amnon]

By stdlib, you presumably mean the x/net/websocket package, which is simple 
ad has a clean API.
But it is also frozen, and  has not been updated for 6 years.
Its docs begin with a deprecation notice:

// This package currently lacks some features found in alternative
// and more actively maintained WebSocket packages:
//
//https://godoc.org/github.com/gorilla/websocket
//https://godoc.org/nhooyr.io/websocket

https://github.com/golang/net/blob/master/websocket/websocket.go#L8-L12

Should I ignore this notice and go ahead and build my system ontop of 
x/net/websocket?

What would people recommend, if I need a implementation which is robust, 
secure and performant?

 
On Monday, 12 December 2022 at 20:35:59 UTC ren...@ix.netcom.com wrote:

> You can use the stdlib websocket. See 
> https://github.com/robaho/go-trader/blob/master/internal/exchange/webserver.go
>  for 
> an example. 
>
> On Dec 12, 2022, at 12:57 PM, Amnon  wrote:
>
> Which websocket implementation would people recommend for a new project,
>
>
> now that gorilla/websocket has been archived? 
>
> -- 
> 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/b9bacd1c-62de-4f6f-b249-44464b61cdcen%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/b9bacd1c-62de-4f6f-b249-44464b61cdcen%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>

-- 
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/e49c2e82-9dcb-4771-a88b-65585ca330f1n%40googlegroups.com.

[go-nuts] Which websockets implementation

[Amnon]

Which websocket implementation would people recommend for a new project,
now that gorilla/websocket has been archived?

-- 
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/b9bacd1c-62de-4f6f-b249-44464b61cdcen%40googlegroups.com.

Re: [go-nuts] Linting

[Amnon]

If you want, run any linters of your chosing on the Go standard library,
go through the reports, and see if any are valid - which expose real 
problems,
then feel free to report them here, or submit bug reports. 
On Sunday, 11 December 2022 at 10:03:21 UTC marc...@gmail.com wrote:

> Ok, but does my answer really matter? Because in the end it's what any 
> linter will tell us about the software.
> And since it is not hard to do, my suggestion always is to make use of 
> some of the great linters that exist.
>
> In a new project I always start off with all the linters (in 
> golangci_lint) active, and then deactivate the ones that I don't want.
> You can also do it the other way around, just a matter of "how to begin 
> with linting".
> The advantage of using some linter would be that it is also a kind of 
> quality fixation on the code.
> Perhaps deciding on which linter(s) to use at first and then slowly 
> "inject" more.
>
> This post is not about finger-pointing btw, because if needed, I would 
> offer my help with this.
> But I won't touch the functions with the high cognitive complexity ;-)
>
> Op za 10 dec. 2022 om 22:34 schreef 'Dan Kortschak' via golang-nuts <
> golan...@googlegroups.com>:
>
>> On Sat, 2022-12-10 at 14:44 +0100, Marcello H wrote:
>> > golangci_lint ...
>> >
>> > Op za 10 dec. 2022 om 13:17 schreef Brian Candler
>> > :
>> > > The question remains, which linter(s) are you using?
>>
>> golangci_lint is not really an answer to this question since it's just
>> a collection of linters, many of which have arguable utility/value.
>>
>> -- 
>> 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/MM3W5oNw4-0/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/9827b253f9d8cc8c821874675adad2130612060e.camel%40kortschak.io
>> .
>>
>

-- 
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/ada8c6a9-25f7-4a64-87d7-3a1553f5d436n%40googlegroups.com.

[go-nuts] Re: Go 1.17.1 runtime seems retain too much memory from OS

[Amnon]

Have a look at https://tip.golang.org/doc/gc-guide

and 
https://opensourcelive.withgoogle.com/events/go-day-2022/watch?talk=talk4

On Thursday, 24 November 2022 at 05:08:55 UTC Zhao Weng wrote:

> [image: memory.jpg]
> memstats show heapIdle - heapReleased > heapAlloc or heapInUse
>
> I try to search the code and found the below comment:
>
> // HeapIdle is bytes in idle (unused) spans.
> //
> // Idle spans have no objects in them. These spans could be
> // (and may already have been) returned to the OS, or they can
> // be reused for heap allocations, or they can be reused as
> // stack memory.
> //
> // HeapIdle minus HeapReleased estimates the amount of memory
> // that could be returned to the OS, but is being retained by
> // the runtime so it can grow the heap without requesting more
> // memory from the OS. If this difference is significantly
> // larger than the heap size, it indicates there was a recent
> // transient spike in live heap size.
> HeapIdle uint64
>
> and from mgcscavenge.go:
>
> // That goal is defined as: 
> // (retainExtraPercent+100) / 100 * (heapGoal / lastHeapGoal) * 
> last_heap_inuse
>
> it seem to me heapIdle - heapReleased should be ~ heapInUse * 10%
>
> can anybody help me understand this?
>
> many thanks!!
>

-- 
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/b63e9b4b-efb4-4209-aaf1-fb4783b41fbdn%40googlegroups.com.

Re: [go-nuts] Problems with array slicing reliability?

[Amnon]

As others have said, it is worth trying to reduce the program to the 
minimal version which reproduces your problem
(and then publishing it on https://go.dev/play/ ).


On Thursday, 24 November 2022 at 02:38:30 UTC kra...@skepticism.us wrote:

> You cannot mutate strings. Your code is also missing a final close-brace 
> and possibly has other problems. That your example includes commented out 
> code is also problematic. As Nikhilesh Susarla pointed out you should post 
> a link to the Go playground to avoid any ambiguity.
>
> I added the missing close-brace to your code and observed the following 
> behavior (I entered "1" at the prompt):
>
> > go run x.go 
>  144.6 ms
> State where the hash counter should begin:>> 1
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x2 addr=0x28 pc=0x102536674]
>
> This tells me there is a fundamental bug in your code having nothing to do 
> with "Problems with array slicing reliability"
>
> On Wed, Nov 23, 2022 at 1:56 PM Mucas Schlack  wrote:
>
>> Hello Golangers!
>> Is there anyone who can test the reliability of the following Golang 
>> slice feature? I am using an AMG64 computer with Windows 10, and Go version 
>> 0.36.0. When I use the following code, to detect and then replace a 
>> character at any given length *n* (9) in a string with an Uppercase 
>> Character. Strangely and somehow, the slice pointer will move to another 
>> position even though the code is not dynamic and has not changed. Is there 
>> anyone who can trouble shoot this code for me?
>>
>> Please remember that this is "*test*" code only, so some of it will not 
>> make any sense or work. It is only "proof of concept" code.
>>
>> The code to pay attention to is the following - from lines: 80 - 92!
>>
>> Many thanks for any help you can give!
>>
>> Mucas
>>
>> Example code:
>>
>> package main
>>
>> import(
>> //"unicode/utf8"
>> "math/rand"
>> "strconv"
>> "strings"
>> "fmt"
>> "time"
>> "os"
>> )
>>
>> var alphanumerics = [62] string {
>> 
>> "a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z",
>> "0","1","2","3","4","5","6","7","8","9",
>> 
>> "A","B","C","D","E","F","G","H","I","J","K","L","M","N","O","P","Q","R","S","T","U","V","W","X","Y","Z",
>> }
>>
>> func main(){
>>
>> var (
>> txtflpth string = "C:\\Workspace\\Transaction Hash.txt"
>> flNm string = "Transaction Hash.txt"
>> CRLF string = "\n"
>> cntstrt string
>> AuthKey string
>> NwStr string
>> cstart int
>> cntr int
>> flEx *os.FileInfo
>> flEx2 *os.File
>> trfl *os.File
>> err error
>> ) 
>>
>> fmt.Print("State where the hash counter should begin:>> ")
>> fmt.Scanln()
>>
>> if cntstrt == "" || cntstrt == " " { 
>> trfl, err = os.Create(flNm)
>> 
>> if err != nil { panic(err); os.Exit(-1) }
>> defer trfl.Close() 
>>
>> } else {
>> var flEx, err = os.Stat(txtflpth)
>> 
>> fmt.Println(flEx.Mode().String)
>> //fmt.Println(flEx.IsRegular())
>> fmt.Println(flEx.IsDir())
>> fmt.Println(flEx.Name())
>> fmt.Println(flEx.Size())
>> fmt.Println(flEx.Sys())
>>
>> if err != nil { if os.IsNotExist(err) { panic(err) } }
>> 
>> cstart, err = strconv.Atoi(cntstrt)
>> flEx2, err := os.Open(txtflpth)
>> defer flEx2.Close() 
>> }
>>
>> /*defer func(
>> if err == trfl.Close() || err == os.IsNotExist(err)!= err { 
>> panic(err) }
>> if err == flEx.Close() || err == os.IsNotExist(err)!= err { 
>> panic(err) }
>> )*/
>>
>> if cntstrt != "" && cntstrt != " " { cntr = cstart }
>>
>> for cntr = cstart; cntr < cstart + 1000; cntr++ {
>> NwStr = ""
>> AuthKey = NwStr
>>
>> for i := 0; i <= 65; i++ {
>> time.Sleep(10 * time.Nanosecond)
>> rand.Seed(time.Now().UnixNano()) 
>> AuthKey = AuthKey + alphanumerics[rand.Intn(62)] //, [A - Z], 
>> [0-9])
>> }
>>
>> var hashRemap = [...] string {"A","U","G","D","E","X"}
>> 
>> AuthKey = "0x" + AuthKey
>> fmt.Println("Transaction Hash: " + strconv.Itoa(cntr) + ") " + 
>> AuthKey)
>> //AuthKey2 := []rune(AuthKey)
>>
>> StrPos := strings.Index(AuthKey, AuthKey[9:10])
>> fmt.Printf("The old character %s is at string position: (%d) " + 
>> CRLF,AuthKey[9:10], StrPos)
>> //os.Exit(1)
>>
>> for i := 0; i < 6; i++ {
>> switch i {
>> case 0: AuthKey = strings.Replace(AuthKey,AuthKey[9:10], 
>> hashRemap[0], 1); fmt.Println("Replaced! The New Transaction Hash: " + "(" 
>> + strconv.Itoa(i) + ") " + AuthKey); os.Exit(1);
>> case 1: AuthKey = 

[go-nuts] Re: Building a Package With Multiple Subdirectories?

[Amnon]

Don't do it.
Don't fight the Go tools. Use them the way they are intended. They are your 
friends.
Put all your package files in a single directory. Or break them up into 
multiple packages.
That is the way everyone else write Go. If you follow the convention, your 
life will be simpler,
and your code will be easier for others to understand and maintain.


On Tuesday, 22 November 2022 at 01:15:33 UTC jlfo...@berkeley.edu wrote:

> Back in June I asked why Go requires all the files in a package to be in 
> the same 
> directory. I learned that this is an implementation-specific decision. I 
> was also referred to
>
>
> https://stackoverflow.com/questions/45899203/can-i-develop-a-go-package-in-multiple-source-directories
>
> which discusses this. Someone named "Volker" in this posting said
>
> "Yes, this is doable without any problems, just invoke the Go compiler by 
> hand, that is not 
> via the go tool."
>
> I'm wondering how to actually do this. Suppose I have a directory, which 
> contains several
> subdirectories. There are .go files in all these directories that I'd like 
> to use to make a
> single package. How could I invoke to Go compiler by hand to make this 
> happen?
> (I've tried adding the "-x" flag to "go build" but I don't see which 
> arguments I'd need to 
> change to do what I'm trying to accomplish). Volker says "It's complicated
> ".
>
> Also, let's say I was able to figure this out. Would using such a package 
> confuse any of
> the other commands in the Go tool chain or the dlv debugger?
>
> Cordially,
> Jon Forrest
>
>
>

-- 
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/f4f1dca8-6e19-4f71-9a62-45097cf43872n%40googlegroups.com.

[go-nuts] Re: Go 1.20 release date

[Amnon]

Feb 2023 is a good bet.

On Tuesday, 22 November 2022 at 10:24:07 UTC piotr.w...@gmail.com wrote:

> Hi,
>
> is the date of the 1.20 release roughly known? I need some goodies it 
> promises to provide.
>
> Best regards, Piotr 
>

-- 
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/ef295ef6-7148-4107-aa6b-55ffda441f2fn%40googlegroups.com.

Re: [go-nuts] Goroutine to thread mapping

[Amnon]

Go makes no guarantees about the affinity between goroutines and threads, 
and the mapping does  typically jump around a lot during the execution of a 
program.

On Monday, 7 November 2022 at 17:46:42 UTC ren...@ix.netcom.com wrote:

> Do you mean Go assembly or an assembly function called via CGo?
>
> On Nov 7, 2022, at 11:28 AM, Piotr Wyderski  wrote:
>
> 
>
> Hello,
>
> A goroutine needs ultimately to be assigned to an OS thread. If a 
> goroutine calls an assembly function F, can the thread assignment change 
> during the execution of F? 
> In other words, is F guaranteed to return on the same thread it was called?
>
>Best regards, Piotr
>  
>
> -- 
> 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/03f2cf25-7e52-41ca-ac20-a04877d5df9dn%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/528a725e-1c74-49d3-9ecb-fb99e8e439f2n%40googlegroups.com.

Re: [go-nuts] What is the best way to write MarshalBinary if the data is a sequence of ints

[Amnon]

What is best depends on what you want to achieve.
Do you want the most compact encoding? Or the fastest encoding? 
Or the encoding which is easiest to debug? Or the simplest encoding?
Or an encoding which allows you to gracefully add fields to the type as 
your program evolves without invalidating persisted data?

You state that your type is easily represented as a sequence of ints. But I 
would ask whether converting to ints is an unnecessary 
step which will lead to less clear code?

Hope this helps

On Sunday, 23 October 2022 at 08:00:36 UTC+1 mb0 wrote:

> hi travis,
>
> if you can use any encoding you like, you can write your own custom
> encoding that uses a varint encoding. the binary encoding interface
> implies that the framing or length segmenting of the raw bytes happens
> outside that function, so you can just read and write all your ints
> using the varint functions from package encoding/binary.
>
> https://pkg.go.dev/encoding/binary?utm_source=godoc#Varint
>
> hope that helps
>
> On 10/22/22 18:12, Travis Keep wrote:
> > The type I am writing can be easily encoded as a sequence of ints. When 
> > I wrote MarshalBinary for my type, I decided to GobEncode this sequence 
> > of ints to a byte buffer and return the bytes.  I learned that 
> > GobEncoding an empty slice of int takes 18 bytes.  So even for small 
> > instances of my type, I am paying for 18 extra bytes of overhead to 
> > encode.  I chose Gob because it uses variable length encoding for ints, 
> > so smaller ints require fewer bytes to encode.
> > 
> > Since I know that I will always be encoding and decoding an []int, is 
> > there a better way to implement MarshalBinary without reimplementing the 
> > variable length encoding of ints from scratch?
> > 
> > Thank you in advance.
> > 
> > 
> > -- 
> > 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/983c6c04-2473-42f1-be29-371e85d66480n%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/golang-nuts/983c6c04-2473-42f1-be29-371e85d66480n%40googlegroups.com?utm_medium=email_source=footer
> >.
>

-- 
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/aa4fcda6-9d0c-4f92-9234-93dd3d9f85f2n%40googlegroups.com.

[go-nuts] Re: Replace reference path

[Amnon]

try https://pkg.go.dev/golang.org/x/tools/cmd/gomvpkg


On Friday, 21 October 2022 at 16:58:57 UTC+1 mr@gmail.com wrote:

> I'm looking for a tool like this, I've searched google and github and 
> can't find one, have you guys used such a tool?
>
> I use a method like this in my code
>
> k8s.io/apimachinery/pkg/util/diff.ObjectReflectDiff
>
> k8s.io/apimachinery/pkg/util/diff is his import path, later I want to 
> switch to another method.
>
> github.com/google/go-cmp/cmp.Diff
>
> github.com/google/go-cmp/cmp is his import path.
>
> I would like to ask if there is a more convenient tool for replacing the 
> whole project?
>
> k8s.io/apimachinery/pkg/util/diff.ObjectReflectDiff -> 
> github.com/google/go-cmp/cmp.Diff
>

-- 
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/57c42d1b-32a5-4e69-95dc-1e0264d8988bn%40googlegroups.com.

[go-nuts] Re: Facing issues while using builtin functions while executing golang templates

[Amnon]

Unrelated. But it may be worth updating to Go 1.19 as Go 1.15 over 2 years 
old, and no longer supported.

To get an answer to your original question, I would post a code snippet 
here which reproduces the problem. 
Also, do you know what triggers this error condition?
On Thursday, 20 October 2022 at 14:39:29 UTC+1 michael...@gmail.com wrote:

> I did a quick search for "is not a defined function".  That message 
> appears once in https://go.dev/src/text/template/exec.go.  It's triggered 
> when findFunction() fails while executing a template.
>
> Hope that's of some use.
>
>
> On Wednesday, October 19, 2022 at 8:20:46 AM UTC-4 rit...@ext.dunzo.in 
> wrote:
>
>>
>> We are facing a strange issue within one of our services where randomly 
>> one of the docker containers in production out of (N,  N>50)  starts 
>> randomly failing on an API while trying to execute a golang template with 
>> an error *"Err: template: : executing \"\" 
>> at len: \"len\" is not a defined function".  *`len` is a builtin 
>> function within golang so am stumped why this error comes.  Some more 
>> context
>>
>>
>>- *Golang Version: 1.15*
>>- The same Pod was serving this API and executing the template 
>>correctly before this issue started coming
>>- Parsing the template works fine, only executing fails. We are 
>>parsing and executing in sequence.
>>- After this error was encountered first, all subsequent API calls to 
>>the same container failed with the same error
>>- The same API on all other containers works perfectly fine.  We 
>>removed the container from serving prod traffic, and this issue 
>> disappeared
>>- This is the second time the issue is happening, first time we 
>>restarted the container and hence weren't able to debug much
>>-  Binary is stripped of symbol tables and ptrace is not enabled
>>
>> We have the container running (not serving prod traffic) so if there are 
>> any hints on how to debug this issue would appreciate.
>>
>

-- 
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/5ff901ef-1643-4913-8f9a-22367a1883a3n%40googlegroups.com.

[go-nuts] Re: go runtime in shared libs functions called in threads

[Amnon]

Each thread has its own stack, but little else.

On Wednesday, 19 October 2022 at 14:28:20 UTC+1 pe...@wonderland.org wrote:

> I have built a shared lib in Go to replace an old thing we use to send 
> email - mainly to modernise things and add TLS and authentication. We run 
> each call to the entry point in it's own thread in the main program.
>
> I am both curious but also concerned about what happens here with go 
> runtimes. I presume each thread has it's own runtime, and on exit it is 
> torn down, but I may be wrong and would like to know more.
>
> Thanks!
>

-- 
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/9844b0a1-fd68-4b84-a909-282d1c3ba249n%40googlegroups.com.

[go-nuts] Re: GO API to upload a directory in the github

[Amnon]

Have a look at https://github.com/go-git/go-git

On Wednesday, 28 September 2022 at 05:46:29 UTC+1 princ...@gmail.com wrote:

> HI Everyone,
> I want to write an go script, to upload a folder in the github. Can anyone 
> please let How I can do this. Is there any resources available for this.
> Please help me in this.
>
> Eg: I have a temp folder in my local machine, I want to upload it to one 
> of the github 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/266dfc81-5e3b-4fb3-a371-d369afd65e06n%40googlegroups.com.

[go-nuts] Re: Using golang variable in bash script Command

[Amnon]

What happens if the user enters the string "'; rm -fr ~;'" ?

On Monday, 19 September 2022 at 13:25:31 UTC+1 Brian Candler wrote:

> On Monday, 19 September 2022 at 10:50:36 UTC+1 princ...@gmail.com wrote:
>
>>
>> *search:=scanner.Text()cmd1,err:=exec.Command("bash", "-c", "find . -name 
>> '*$search*'")*
>
>
> You first "search" is a go local variable.
> Your second "$search" is seen by the shell as a reference to an 
> environment variable.
>
> So if you want to do it that way, you need to set it in the environment, 
> e.g. with os.Setenv.
> https://pkg.go.dev/os#Setenv
>

-- 
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/e2aafbd7-3f67-4170-aee1-489cf8c26540n%40googlegroups.com.

[go-nuts] Re: Python cool methods in Golang

[Amnon]

Go for it!

Write a few methods. 
Put it on github
and post a link here.

Best of luck!
On Saturday, 20 August 2022 at 11:29:37 UTC+1 harald@gmx.net wrote:

> Not showing the code and attaching a (INAL) useless "confidentiality 
> notice" (good luck arguing with Google over that) looks like a big "no-go" 
> to me. What exactly is your intention?
>
> On Thursday, August 18, 2022 at 12:52:42 AM UTC+2 andres...@rappi.com 
> wrote:
>
>> Hi !
>> Currently I am working on a new library to simulate some cool and useful 
>> Python methods like (Extends, pop, contains, sets, heapify , etc) with Go 
>> 1.18 , I wanna know if you might find it useful and if someone wants to add 
>> stuff or help are more than welcome.
>> My personal email is af.ba...@uniandes.edu.co if someone would like to 
>> chat or contribute
>> Thanks
>>
>> *CONFIDENTIALITY NOTICE: *The contents of this email message and any 
>> attachments are intended solely for the addressee(s) and may contain 
>> confidential and/or privileged information and are legally protected from 
>> disclosure. If you are not the intended recipient of this message or their 
>> agent, or if this message has been addressed to you in error, please 
>> immediately alert the sender by replying to this email and then delete this 
>> message and any attachments. If you are not the intended recipient, you are 
>> hereby notified that any use, dissemination, copying, or storage of this 
>> message or its attachments without authorization is strictly prohibited.
>>
>

-- 
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/f808efd5-56e1-471f-af22-97c0ca1c96a8n%40googlegroups.com.

[go-nuts] Re: Discussion: standard iterator interface proposal

[Amnon]

This is a very good proposal.
The use of the range keyword does scare me. But I'll get used to it 
eventually.
And I will need a lot more coffee to get my head around the appendix about 
coroutine optimisations.
But overall this will be a very useful addition which will make a lot of 
code more consistent and more simple.


On Thursday, 4 August 2022 at 01:24:10 UTC+1 Ian Lance Taylor wrote:

> I've just opened a discussion for a standard iterator interface. This
> is intended to describe a framework that future generic containers
> will implement. If you are interested in this topic, please see
> https://go.dev/issue/54245.
>
> We welcome all comments, but please be aware that this is an area that
> is wide open for bikeshedding. Before commenting, please make an
> effort to ensure that you are not repeating comments that others have
> already made. Thanks.
>
> 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/ebdc485f-f4fd-47ff-81e3-fe3d868c516cn%40googlegroups.com.

Re: [go-nuts] Minimizing net latency?

[Amnon]

Go is designed to maximize throughput, rather than minimize latency. 

Where does latency come from?

0) serialization delay reading the NIC (packet length/network speed)
1) when a packet arrives the NIC DMA's its contents into memory  
2) the NIC then waits to see if more packets arrive (about 60us) - this can 
be turned off using ethtool's interrupt moderation settings. 
3) The NIC raises an interrupt
4) The interrupt handler puts the packet onto the lower part of the device 
driver's queue
5) eventually the device driver gets scheduled, and passes the packet into 
the kernel's TCP or UDP networking code
6) this code will check sequence numbers, send ACKs, figure out which 
process will read the packet (i.e. your Go executable), and move it from 
the 
list of sleeping process to the list of runnable processes
7) at some point later the kernel will resume your now runnable process
8) The netpoller in your executable will read the data, and figure out 
which Goroutine is sleeping on this socket, and make it runable
9) Go's scheduler will at some point later, schedule that Goroutine so that 
it resumes running and consumes your packet.

So this is what happens when you read a packet. Sending a packet is similar 
but backwards, but with lots of steps missed out.

So where does latency come from?

The biggest one is 9 - waiting for the Go scheduler to schedule your 
Goroutine - this could take a long time, depending on the load on your 
system.
That is the cost of Go's netpoller which can efficiently mtiplex io over 
100,000s of Goroutines

The next is 7 (the Os scheduler)

And then 2 (interrupt moderation) - which accounts for up to 60us but is 
very easy to fix,

If you are in the HFT business and loose vast amounts of money for each us 
delay, then you can do crazy and ugly stuff with 
kernel bypass and code locked on CPU cores busywaiting on the device 
ringbuffer.

But for sane people Go gives you a great compromise of superb scalability 
(avoiding the thundering herd problem) while maintaining acceptable latency.

On Saturday, 30 July 2022 at 03:34:45 UTC+1 ren...@ix.netcom.com wrote:

> It is probably not the data in the cache - it is the code - whether yours 
> or the kernel.
>
> Did you try “hot threading” with polling in the C code? Did you see the 
> same results?
>
> Typically a context switch on modern linux is 6 usecs - so I am doubting 
> that is the source of your latency.
>
> On Jul 29, 2022, at 8:11 PM, TH  wrote:
>
> In case of cache miss, I assume there's no way to tell CPU to keep the 
> data in the cache? The structs related to processing is all below cache 
> line size. (the test code is very crude one, not really much processing 
> done)
>
> On the dedicated thread polling sockets... could I move away net and use 
> syscall & poll to implement low latency? But then again I'm seeing this 
> similar behaviour on my C code too.
>
> Thanks
>
> On Saturday, 30 July 2022 at 03:16:09 UTC+3 ren...@ix.netcom.com wrote:
>
>> Since the net IO is abstracted away from you, the answer is ’not usually’.
>>
>> The usual solution is dedicated threads that constantly poll the sockets, 
>> or hardware support + real-time threads, etc.
>>
>> BUT, typically this is not what you are experiencing. More likely, the 
>> cpu cache gets cold - so the operations can take 10x longer - especially on 
>> a multi-use/user system - so it is actually your processing code that is 
>> taking longer.
>>
>> You can probably use ‘perf’ on the process to monitor the cache misses.
>>
>> On Jul 29, 2022, at 7:08 PM, TH  wrote:
>>
>> Hey,
>>
>> Bit confused on how stdlib net is implemented, but I'm noticing round 
>> trip >150µs latencies on idle connections (loopback). Round trip latency 
>> will drop to <20µs if sent packets constantly.
>>
>> I assume that this latency is caused by kernel / syscall wakeup to 
>> indicate that new data has arrived. Are there any methods to minimize this 
>> wakeup latency?
>>
>> Thanks
>>
>>
>> -- 
>> 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/87deab65-b441-42ce-b51b-663651ecfccbn%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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a6d4d1ed-d1e9-4a60-a346-83b5eadd2d68n%40googlegroups.com
>  
> 

Re: [go-nuts] Will Go be discontinued?

[Amnon]

On Monday, 25 July 2022 at 19:48:24 UTC+1 Carlos Jimenez wrote:

> I think it will be discontinued soon 
> The average lifespan of a discontinued Google product is *4 years and 1 
> month*. so should be a matter of months maybe 2.0 will be the last one 
> before shutdown
>

The average lifespan may be 4 years 1 month. But there is a massive 
standard deviation. Some google products (such as Search) seem to have a 
very much longer lifespan.
The mean lifespan of a product is massively skewed by the many experimental 
products which fail fast.

This thread was started in 2013.  has been dormant for 9 years. But Go has 
been anything but
Will Go be discontinued in a matter of months? As Neils Bohr once said, 
"Predictions are difficult, especially concerning the future". 
And never more so than it today's turbulent world. But if I was a betting 
man, I would not put money on Go being discontinued any times soon,
(though perhaps I should, as a hedge against my career being disrupted).

Anyway let's check back in a few months time and see if we are still here...

-- 
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/937d6c13-590b-44aa-84ee-898a60143044n%40googlegroups.com.

[go-nuts] Re: Go build but module-aware mode

[Amnon]

I can't. My problem is that I can't access  github.com// 
.
Either it does not exist.
Or user  has made the repo private on Github.


[image: Screenshot 2022-07-20 at 15.07.31.png]

On Wednesday, 20 July 2022 at 15:04:48 UTC+1 rich...@gmail.com wrote:

> Hi, is there any way to build source from given path@version just like `go 
> run` and `go mod`? 
> What i got:
> > go build -o main_x github.com//@latest
> package github.com//@latest: can only use path@version syntax 
> with 'go get' and 'go install' in module-aware mode
>
> (and maybe putting `GOARCH` and/or `GOOS`)
>
> Thanks
>

-- 
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/65c57e98-e186-42eb-8aa8-b4fb3e795895n%40googlegroups.com.

[go-nuts] Re: duration^2

[Amnon]

On Tuesday, 19 July 2022 at 17:14:19 UTC+1 agra...@googlemail.com wrote:

> hello,
> i am new to everything is new in programming-heaven. old-c-guy. and i 
> thought it`s time to learn something most-modern ..
>

Welcome!

Go is a great language for old-c-guys (and girls). Go was,  in fact mainly 
invented by them...
You will have fun here...


 

>
>
> time.NewTicker( time.Second )   ok
> time.NewTicker( 5 * time.Second ) ok
> var n int = 5  
> time.NewTicker( n * time.Second ) error : int * duration 
> time.NewTicker( time.Duration(n) * time.Second )  ok : duration * 
> duration [s^2] square-seconds ?
>

Yes, this bothers the inner Physicist in me too.
But you can only multiply numbers if they are of the same type...
 

>
>
> tick := time.NewTicker( time.Duration( math.rand.Intn(10) ) * time.Second 
> ) 
>
> go func() { for { select {
>  case <-done : return 
> ,case tc := <-tick.C :  tick  
> }}}()
>
> this strategy gets the tick if it has already happend in past and this 
> go-routine is active
> if it is suspended will it be notified as soon in either done or tick 
> something is to read ?
>

Yes
 

>
>
> when i (later) write own code / interfaces / struct where inside is like 
> in ticker the .C a channel, can i define something like an operator, so 
> that the outer object acts like a channel
>

You want user defined operations - so you can define the implementation of 
the <- operator on your type.
 But we don't have this in Go.
You need to use methods. (Less syntactic sugar, but more clarity).



>
> type S struct {
>  C chan time 
>  ..
> }
> s := S{C:make(chan time),..}
> s<- 
> <-s 
>

-- 
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/831b14b4-6a34-4ef2-85ef-858c74c1cc27n%40googlegroups.com.

[go-nuts] Re: Golang API to fetch available versions and release features

[Amnon]

does 
https://go.dev/dl/?mode=json 
have the info you need?

On Monday, 13 June 2022 at 17:08:03 UTC+1 durgasomes...@gmail.com wrote:

> Hi Team,
>
> Can someone help me with below queries. 
>
> 1) Do we have any official Golang/Google API to get latest available 
> Golang versions both major and minor. If yes, is it possible to fetch 
> release data (both features & fixes information) for a specific version.
>
> 2) Can we get release/fix versions information based on category like 
> Security.
>
>
> I am not sure whether above queries are supporting by Golang team or not. 
> If available, please help me with information and official documentation.
>
>
> Thanks & Regards,
> Durga Someswara Rao Gullapudi.
>

-- 
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/4bed815a-70d9-43d1-868e-be9edace624en%40googlegroups.com.

Re: [go-nuts] Re: Go 1.19 Beta 1 is released

[Amnon]

debug.SetMemoryLimit will be useful (for me at least).
But a bit disappointed not to see a fix 
for https://github.com/golang/go/issues/50603.

On Sunday, 12 June 2022 at 05:51:23 UTC+1 ben...@gmail.com wrote:

> I'm quite looking forward to the performance improvements we'll get for 
> free (i.e., by just upgrading): sort will be faster, large switch blocks 
> will be faster due to now using jump tables (good for interpreter 
> opcode-dispatch loops), and regexp will be a little faster due to a 
> pointer-vs-value optimization (
> https://go-review.googlesource.com/c/go/+/355789 -- not mentioned in the 
> Go 1.19 release notes).
>
> -Ben
>
> On Sunday, June 12, 2022 at 9:27:27 AM UTC+12 Ian Lance Taylor wrote:
>
>> On Sat, Jun 11, 2022 at 12:30 AM Amnon  wrote:
>> >
>> > What are the biggest, and most exciting changes coming in 1.19?
>>
>> The draft release notes are at https://tip.golang.org/doc/go1.19 .
>>
>> 1.18 was a big release with a lot of exciting changes. 1.19 is more
>> of a relaxed, catch your breath release. Personally I think the most
>> exciting change is runtime/debug.SetMemoryLimit.
>>
>> 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/bb037f28-5185-47fb-a439-23f61b7d716fn%40googlegroups.com.

[go-nuts] Re: Go 1.19 Beta 1 is released

[Amnon]

Cool!

What are the biggest, and most exciting changes coming in 1.19?

On Friday, 10 June 2022 at 18:51:02 UTC+1 anno...@golang.org wrote:

> Hello gophers,
>
> We have just released go1.19beta1, a beta version of Go 1.19.
> It is cut from the master branch at the revision tagged go1.19beta1.
>
> Please try your production load tests and unit tests with the new version.
> Your help testing these pre-release versions is invaluable.
>
> Report any problems using the issue tracker:
> https://go.dev/issue/new
>
> If you have Go installed already, the easiest way to try go1.19beta1
> is by using the go command:
> $ go install golang.org/dl/go1.19beta1@latest
> $ go1.19beta1 download
>
> You can download binary and source distributions from the Go website:
> https://go.dev/dl/#go1.19beta1
>
> To find out what has changed in Go 1.19, read the draft release notes:
> https://tip.golang.org/doc/go1.19
>
> Cheers,
> Cherry, Heschi, Alex, 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/24aad2a2-2a17-40bd-a875-1d69d9fea5c6n%40googlegroups.com.

[go-nuts] Re: Golang and virustotal

[Amnon]

My workaround is not to use Windows.
And not to use anti-virus programs that thing all Go programs are viruses.

On Friday, 13 May 2022 at 16:21:31 UTC+1 drro...@gmail.com wrote:

> My work around is to compile using  -ldflags="-s -w"
>
> This has worked for the cases when my files make Windows unhappy.  I 
> reported it as a bug to Microsoft months ago; I see that they got right on 
> it.
>
> --rob solomon
>
>
> On Wednesday, May 11, 2022 at 11:50:20 AM UTC-4 Rusco wrote:
>
>> Regarding: "compile a simple helloworld main ...": 
>>
>> My workaround is to insert a
>>   import "C"
>> among the other imports. It somehow alters the structure of the binary 
>> created and my av no more recognizes the binary. This is actually something 
>> which never happened when I am doing some Rust work.  
>>
>> Might help.
>>
>>
>> On Friday, 29 April 2022 at 11:22:38 UTC+1 Paolo C. wrote:
>>
>>> Hello,
>>> I noticed that if you download golang portable zip for aMD64 and upload 
>>> the
>>> go.exe or gofnt.exe to virustotal one av complains.
>>> If you compile a simple helloword main and upload, 4 or 5 minor av 
>>> complain.
>>> Anyone has this issue too?
>>> I tested this from many machines, some completely virgin, so it should 
>>> not be my environment.
>>> Thanks
>>> Paolo
>>>
>>

-- 
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/9e4a55fb-0174-43fd-91da-091eaab3ad4en%40googlegroups.com.

Re: [go-nuts] Re: Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it?

[Amnon]

> I'm not sure why w.Write would freeze; is your process starting to swap
> and it is not really frozen but just taking a long time? Is it being
> killed by the kernel's out-of-memory monitor?

In the OP's code, w.Write was writing a large amount of data to a pipe, 
while nothing was reading from the other end.
This was the reason for the deadlock.

-- 
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/53825010-ea65-4f69-8576-bfad38021acen%40googlegroups.com.

Re: [go-nuts] Is there a compiler directive to use the Go version set in go.mod instead of the current toolchain version?

[Amnon]

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: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 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 install back Go toolchain 1.15? 
>>
>> I don't think that what you want to do is supported. I recommend that 
>> you install 1.15 somewhere. 
>>
>> That said, you could try "go build -gcflags=-lang=go1.15". 
>>
>> Ian 
>>
>
>  "go build -gcflags=-lang=go1.15" doesn't work too.
> OK, I will try to install 1.15 alongside.
>

-- 
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/e3d92a7b-3364-4731-9b41-6277517852d7n%40googlegroups.com.

[go-nuts] Re: How to write 100MB string to STDOUT

[Amnon]

Why not upload your entire unit test to https://go.dev/play/ so we can have 
a look at what you are doing?

On Sunday, 8 May 2022 at 23:45:15 UTC+1 Const V wrote:

> In order to test I temporarily use a pipe in order to get the string from 
> the stdout.
>
> tempStdout := os.Stdout
> r, w, _ := os.Pipe()
> os.Stdout = w
>
> r1 := bufio.NewReader(file)
> s := ReadWithReadLine(r1)
>
> // output to stdout is intercepted in order to get it as a string for 
> testing
> InputProcessing(strings.NewReader(s), os.Stdout)
>  w.Close()
>
> out, _ := ioutil.ReadAll(r)
> os.Stdout = tempStdout
>
> observed := string(out)
>
> later - testing expected and observed outcome
> 
>
> if observed == expected {
> t.Fatalf("\n%s, \nwant: %s\n", observed, expected)
> }
>
> On Sunday, May 8, 2022 at 3:24:06 PM UTC-7 Amnon wrote:
>
>> How did you reach the conclusion that it is not working?
>> What is your stdout connected to?
>>
>> On Sunday, 8 May 2022 at 22:24:16 UTC+1 Const V wrote:
>>
>>> I'm submitting as a separate post to focus on the following problem I 
>>> have:
>>>
>>> writing 100MB string to STDOUT
>>> w io.Writer
>>> w.Write([]byte(s))
>>>
>>> For smaller size string it is working. For bigger
>>> like 100MB it is not.
>>>
>>> I'm looking to submit chunks of the string like 1KB subsequently to 
>>> STDOUT
>>> until all string content is sent.
>>>
>>

-- 
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/390eb84f-22c5-4d3a-8160-e6c876d83e3dn%40googlegroups.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon]

So what happens when you run your program > /dev/null
?

For testing I would write a function that reads from an io.Reader and 
writes to an io.Reader.
Write a unit test which uses a bytes.Buffer to catch the output.

On Monday, 9 May 2022 at 04:59:37 UTC+1 Const V wrote:

> I'm using OSX. 
>
> The only reasonI need to redirect is to catch the STOUT output in a string 
> for testing,
> It seems Pipe has limited capacity. May be there is another way.
>
> On Sunday, May 8, 2022 at 8:33:09 PM UTC-7 Amnon wrote:
>
>>
>> Why don't you try redirecting stdout to /dev/null and see how your 
>> program behaves.
>>
>> Also, which OS are you using?
>>
>> On Sun, May 8, 2022 at 11:36 PM Const V  wrote:
>>
>>> reading 1 line '\n' delimited 100MB file 
>>> r1 := bufio.NewReader(file)
>>> s := ReadWithReadLine(r1)
>>> InputProcessing(strings.NewReader(s), os.Stdout)
>>>
>>> in InputProcessing"
>>> w.Write([]byte(s)) -> waiting forever
>>> w.Write([]byte(s)[:100]) -> working
>>> ---
>>> func InputProcessing(r io.Reader, w io.Writer) {
>>> find := "error"
>>> /
>>> s := ReadWithReadLine(r)
>>> if strings.Contains(s, find) {
>>> w.Write([]byte(s)[:100])
>>> w.Write([]byte("\n"))
>>> } else {
>>> w.Write([]byte(" \n"))
>>> }
>>> }
>>> ---
>>> On Sunday, May 8, 2022 at 3:21:52 PM UTC-7 Amnon wrote:
>>>
>>>> On Sun, May 8, 2022 at 10:41 PM Const V  wrote:
>>>>
>>>>> write to stdout is not working for MB long strings
>>>>>
>>>>>>
>>>>>>
>>>> That is very surprising indeed.
>>>> How do you reach the conclusion?
>>>> How can we replicate that failure?
>>>>
>>> -- 
>>> 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/IUMIxWx9aLk/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/b1259910-58ca-4a57-bb05-1dde2fc73443n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/golang-nuts/b1259910-58ca-4a57-bb05-1dde2fc73443n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
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/4ffe8196-d9c5-42ad-a713-ae621ff68efan%40googlegroups.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon BC]

Why don't you try redirecting stdout to /dev/null and see how your program
behaves.

Also, which OS are you using?

On Sun, May 8, 2022 at 11:36 PM Const V  wrote:

> reading 1 line '\n' delimited 100MB file
> r1 := bufio.NewReader(file)
> s := ReadWithReadLine(r1)
> InputProcessing(strings.NewReader(s), os.Stdout)
>
> in InputProcessing"
> w.Write([]byte(s)) -> waiting forever
> w.Write([]byte(s)[:100]) -> working
> ---
> func InputProcessing(r io.Reader, w io.Writer) {
> find := "error"
> /
> s := ReadWithReadLine(r)
> if strings.Contains(s, find) {
> w.Write([]byte(s)[:100])
> w.Write([]byte("\n"))
> } else {
> w.Write([]byte(" \n"))
> }
> }
> ---
> On Sunday, May 8, 2022 at 3:21:52 PM UTC-7 Amnon wrote:
>
>> On Sun, May 8, 2022 at 10:41 PM Const V  wrote:
>>
>>> write to stdout is not working for MB long strings
>>>
>>>>
>>>>
>> That is very surprising indeed.
>> How do you reach the conclusion?
>> How can we replicate that failure?
>>
> --
> 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/IUMIxWx9aLk/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/b1259910-58ca-4a57-bb05-1dde2fc73443n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/b1259910-58ca-4a57-bb05-1dde2fc73443n%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CALg-z3X2P%3DEKpg%2BXAK1qUYtAKGYNL4qcQ-NyN-J5Wo7Kc8DLQA%40mail.gmail.com.

[go-nuts] Re: How to write 100MB string to STDOUT

[Amnon]

How did you reach the conclusion that it is not working?
What is your stdout connected to?

On Sunday, 8 May 2022 at 22:24:16 UTC+1 Const V wrote:

> I'm submitting as a separate post to focus on the following problem I have:
>
> writing 100MB string to STDOUT
> w io.Writer
> w.Write([]byte(s))
>
> For smaller size string it is working. For bigger
> like 100MB it is not.
>
> I'm looking to submit chunks of the string like 1KB subsequently to STDOUT
> until all string content is sent.
>

-- 
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/5eb390ae-0fcd-4d48-a4c6-c40a3b1cd738n%40googlegroups.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon BC]

On Sun, May 8, 2022 at 10:41 PM Const V  wrote:

> write to stdout is not working for MB long strings
>
>>
>>
That is very surprising indeed.
How do you reach the conclusion?
How can we replicate that failure?

-- 
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/CALg-z3Uun-qPm2337DOsxyWRosFJRs-XXMu672NjVHhS1e5%3DVw%40mail.gmail.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon]

So you raise a couple of questions:

1) How about handling runes?
The nice thing about utf8 is you don't have to care. If you are searching 
for the word ascii byte 'test', you can 
simply compare byte by byte - the letter t is represented by 0x74, and this 
byte in the search buffer can 
only represent t - it can never be part of a multi-byte-rune - not in utf8.

2) Can we handle lines of hundreds of MB? 
Not really. The default will limit MaxTokenSize to 64K. 
If you set your own buffer (recommended) then the size of this buffer will 
be your maximum line length.
Unfortunately you can't really solve this problem without slurping the 
entire file into memory. Because 
the whole file could consist of a single line, with the word "test" at the 
very end - and at this point, you will 
still need access to the beginning of the file in order to output it.

3) The Mike Haertel message (from 2010) is interesting, as is the reference 
to the paper
"Fast String Searching", by Andrew Hume and Daniel Sunday, in the November 
1991 issue of Software Practice & Experience
All this is a quite old. Computer architecture has changed significantly 
since then, CPUs have got a lot faster and added vector
instructions which speed up dumb algorithms a lot. The relative cost of 
accessing memory has massively increased, as memory
speeds have not increased at anything like the rate of CPU speeds (though 
the Apple M1 system on chips family has changed this)
so memory -> CPU is often the bottleneck,  and optimising CPU performance 
through clever algorithms often merely results in 
the CPU being stuck in stall cycles waiting for cache misses to be serviced.
That said, some of the points Mike makes are still valid. One is the 
massive cost of breaking up lines - which slows down performance
by an order of magnitude, by forcing you to examine every byte. So 
searching for the search-text, and then when you find it, searching 
backwards
from that point to find the enclosing line, is a big win.
The other point he makes which is still valid is to consider the cost of 
copying data. 
This will probably be the dominant cost. Running `cat > /dev/null` will 
tell you how long it takes to merely read the data, and this will give
you a baseline figure. A reasonably carefully written grep clone should 
achieve roughly the same runtime.

As you specified the problem as reading from stdin, using memory mapped 
files, using faster filesystems and fast SSDs will not help you.

And, as always in Go, allocations trump almost everything else. If you end 
up converting each line into a string, forcing allocations and GC work,
that will knock orders of magnitude off your performance. 

Disclaimer: I have not actually written any code or run any benchmarks 
here. But there are some interesting questions which could make an 
interesting paper. To what extent has Hume and Sunday's 1991 paper been 
invalidated by hardware changes? Are smart algorithm's which 
avoid looking at every byte still a win, or do they actually slow down 
performance by adding branch mispredictions, and preventing vectorisation
optimisations? To what extent does the Apple/Arm system on chip family, 
with their much lower memory latency, change these considerations?
How much slower will a simple Go clone of grep be than the C version which 
has had decades of optimisation?
And how much effort would it take to optimise the Go clone to reach the 
performance of the C version?
If anyone wants to write the code, do the benchmarks, and publish the 
conclusions, then send me a link. It will be an interesting read.


On Sunday, 8 May 2022 at 00:55:28 UTC+1 Const V wrote:

> I cannot use fgrep in this environment.
>
> Looks like Scan buffer is resizable.
>
> https://cs.opensource.google/go/go/+/refs/tags/go1.18.1:src/bufio/scan.go;l=190
> // Is the buffer full? If so, resize. 
>if s 
> 
> .end 
> 
>  
> == len(s 
> 
> .buf 
> )
>  
> { 
>// Guarantee no overflow in the multiplication below. 
>const maxInt 
> 
>  
> = int 
> 
> (^uint 
> 

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon]

The other interesting question is what algorithm we use to find the pattern 
in each line.
Generally bytes.Contains uses Rabin-Karp. But as the pattern is the word 
"test" which is only 4 bytes long,
a brute force search is used, using SSE type instructions where available. 
So the naive Go approach will give you a very fast execution. The main 
thing is to set up your scanner with a large buffer, to minimize the number
of file system reads, and to avoid the newbie error of working with strings 
rather than []byte, and forcing the code to do vast numbers of 
unnecessary and expensive allocations.

On Saturday, 7 May 2022 at 22:53:54 UTC+1 Amnon wrote:

> p.s. If you changed the above code to use strings rather than []byte 
> it would run many times slower due to the cost of allocation.
>
> On Saturday, 7 May 2022 at 22:49:08 UTC+1 Amnon wrote:
>
>> How about something like 
>>
>> func grep(pat []byte, r io.Reader, w io.Writer) error {
>> scanner := bufio.NewScanner(r)
>> for scanner.Scan() {
>> if (bytes.Contains(scanner.Bytes(), pat)) {
>> w.Write(scanner.Bytes())
>> }
>> }
>>
>> return scanner.Err()
>> }
>>
>> and for extra speed, just allocate a bigger buffer to the scanner...
>> On Saturday, 7 May 2022 at 21:46:33 UTC+1 Jan Mercl wrote:
>>
>>> On Sat, May 7, 2022 at 10:24 PM Constantine Vassilev  
>>> wrote: 
>>>
>>> > I need to write a program that reads STDIN and should output every 
>>> line that contains a search word "test" to STDOUT. 
>>>
>>> Piping the data through grep(1) would be my first option. 
>>>
>>

-- 
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/ef946f73-7a2e-492e-bfe3-79e7f17962ebn%40googlegroups.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon]

p.s. If you changed the above code to use strings rather than []byte 
it would run many times slower due to the cost of allocation.

On Saturday, 7 May 2022 at 22:49:08 UTC+1 Amnon wrote:

> How about something like 
>
> func grep(pat []byte, r io.Reader, w io.Writer) error {
> scanner := bufio.NewScanner(r)
> for scanner.Scan() {
> if (bytes.Contains(scanner.Bytes(), pat)) {
> w.Write(scanner.Bytes())
> }
> }
>
> return scanner.Err()
> }
>
> and for extra speed, just allocate a bigger buffer to the scanner...
> On Saturday, 7 May 2022 at 21:46:33 UTC+1 Jan Mercl wrote:
>
>> On Sat, May 7, 2022 at 10:24 PM Constantine Vassilev  
>> wrote:
>>
>> > I need to write a program that reads STDIN and should output every line 
>> that contains a search word "test" to STDOUT.
>>
>> Piping the data through grep(1) would be my first option.
>>
>

-- 
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/ee516197-dd8c-4af4-beb7-fa5c503e66b6n%40googlegroups.com.

Re: [go-nuts] Which is the most efficient way to read STDIN lines 100s of MB long and tens of MB info is passed to it

[Amnon]

How about something like 

func grep(pat []byte, r io.Reader, w io.Writer) error {
scanner := bufio.NewScanner(r)
for scanner.Scan() {
if (bytes.Contains(scanner.Bytes(), pat)) {
w.Write(scanner.Bytes())
}
}

return scanner.Err()
}

and for extra speed, just allocate a bigger buffer to the scanner...
On Saturday, 7 May 2022 at 21:46:33 UTC+1 Jan Mercl wrote:

> On Sat, May 7, 2022 at 10:24 PM Constantine Vassilev  
> wrote:
>
> > I need to write a program that reads STDIN and should output every line 
> that contains a search word "test" to STDOUT.
>
> Piping the data through grep(1) would be my first option.
>

-- 
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/a5ab9f72-edd5-44ad-b30e-60aeed57823dn%40googlegroups.com.

[go-nuts] Good overview of Go's design in ACM

[Amnon]

https://cacm.acm.org/magazines/2022/5/260357-the-go-programming-language-and-environment/fulltext

-- 
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/30299f6c-8cda-4d73-8b12-5ae71ee19820n%40googlegroups.com.

[go-nuts] Re: net/http: Why not close the conn directly instead of put the conn into a new list?

[Amnon]

You can close any idle connection.
But when a TCP socket is unused for a while the congestion window is reset, 
and next time it is used,
it will be in slow start mode. So a recently used connection is likely to 
have a larger window size, and allow
faster transmission, than one which has been idle for a long time. 
So when you are deciding which idle connection to close, it is reasonable 
to close the one which has been idle
for longest.

On Tuesday, 26 April 2022 at 13:36:17 UTC+1 chenc...@gmail.com wrote:

> I read golang's source code recently, and find a place that doesn't make 
> sence.
>
> ```
>
> if t.MaxIdleConns != 0 && t.idleLRU.len() > t.MaxIdleConns { 
>
>   oldest := t.idleLRU.removeOldest() 
>
>   oldest.close(errTooManyIdle) 
>
>   t.removeIdleConnLocked(oldest) 
>
> }
>
> ```
>
> the code is here : 
> https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/net/http/transport.go#L984-L988
>
> question: 
>
> when idleConn's length > t.MaxIdleConns, why not close the conn directly 
> instead of putting the conn into a new list. and remove the oldest conn in 
> the list. As I understand it, it's simple to close the redundant 
> connection, and it turns out to be corrent.
>

-- 
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/a07dd7c1-baff-47ae-8457-d18cd0b40973n%40googlegroups.com.

[go-nuts] Re: [security] Go 1.18.1 and Go 1.17.9 are released

[Amnon]

D'oh!
This is a known issue. (I should have checked before posting my original 
message).
https://github.com/golang/go/issues/52317

So if you are an OSX user, then either download for source
Or keep using 1.18 until https://github.com/golang/go/issues/52317 is 
resolved.

On Wednesday, 13 April 2022 at 07:04:19 UTC+1 Amnon wrote:

> Thank for the new release...
>
> I may be looking in the wrong place, but the darwin binaries for 1.18.1 
> appear to be missing.
>
> https://go.dev/doc/install when installing on a mac shows an installer 
> button labeled  "Download Go for Mac"
> which links to https://go.dev/dl/undefined which gives a 404 error.
>
> % go install golang.org/dl/go1.18.1@latest
> % go1.18.1 download 
> fails with
> go1.18.1: download failed: no binary release of go1.18.1 for darwin/amd64 
> at https://dl.google.com/go/go1.18.1.darwin-amd64.tar.gz
>
> Downloading from source, and running all.bash works fine.
>
> Thanks,
> Amnon
>
>
>
> On Wednesday, 13 April 2022 at 02:01:53 UTC+1 dmit...@golang.org wrote:
>
>> Hello gophers,
>>
>> We have just released Go versions 1.18.1 and 1.17.9, minor point releases.
>>
>> These minor releases include three security fixes following the security 
>> policy:
>>
>>- encoding/pem: fix stack overflow in Decode
>>
>>A large (more than 5 MB) PEM input can cause a stack overflow in 
>>Decode, leading the program to crash.
>>
>>Thanks to Juho Nurminen of Mattermost who reported the error.
>>
>>This is CVE-2022-24675 and https://go.dev/issue/51853.
>>
>>
>>- crypto/elliptic: tolerate all oversized scalars in generic P-256
>>
>>A crafted scalar input longer than 32 bytes can cause 
>>P256().ScalarMult or P256().ScalarBaseMult to panic. Indirect uses 
>> through 
>>crypto/ecdsa and crypto/tls are unaffected. amd64, arm64, ppc64le, and 
>>s390x are unaffected.
>>
>>This was discovered thanks to a Project Wycheproof test vector.
>>
>>This is CVE-2022-28327 and https://go.dev/issue/52075.
>>
>>
>>- crypto/x509: non-compliant certificates can cause a panic in Verify 
>>on macOS in Go 1.18
>>
>>Verifying certificate chains containing certificates which are not 
>>compliant with RFC 5280 causes Certificate.Verify to panic on macOS.
>>
>>These chains can be delivered through TLS and can cause a crypto/tls 
>>or net/http client to crash.
>>
>>Thanks to Tailscale for doing weird things and finding this.
>>
>>This is CVE-2022-27536 and https://go.dev/issue/51759.
>>
>>
>> View the release notes for more information:
>> https://go.dev/doc/devel/release#go1.18.minor
>>
>> You can download binary and source distributions from the Go web site:
>> https://go.dev/dl/
>>
>> macOS binary artifacts for Go 1.18.1 are not available at this time due 
>> to an issue <https://go.dev/issue/52317>.
>> We are working on providing them as soon as possible. Sorry for the 
>> inconvenience.
>>
>> To compile from source using a Git clone, update to the release with
>> "git checkout go1.18.1" and build as usual.
>>
>> Thanks to everyone who contributed to the releases.
>>
>> Cheers,
>> Dmitri and Cherry 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/90d82684-9661-4dec-8aad-2651dcd0abb2n%40googlegroups.com.

[go-nuts] Re: [security] Go 1.18.1 and Go 1.17.9 are released

[Amnon]

Thank for the new release...

I may be looking in the wrong place, but the darwin binaries for 1.18.1 
appear to be missing.

https://go.dev/doc/install when installing on a mac shows an installer 
button labeled  "Download Go for Mac"
which links to https://go.dev/dl/undefined which gives a 404 error.

% go install golang.org/dl/go1.18.1@latest
% go1.18.1 download 
fails with
go1.18.1: download failed: no binary release of go1.18.1 for darwin/amd64 
at https://dl.google.com/go/go1.18.1.darwin-amd64.tar.gz

Downloading from source, and running all.bash works fine.

Thanks,
Amnon



On Wednesday, 13 April 2022 at 02:01:53 UTC+1 dmit...@golang.org wrote:

> Hello gophers,
>
> We have just released Go versions 1.18.1 and 1.17.9, minor point releases.
>
> These minor releases include three security fixes following the security 
> policy:
>
>- encoding/pem: fix stack overflow in Decode
>
>A large (more than 5 MB) PEM input can cause a stack overflow in 
>Decode, leading the program to crash.
>
>Thanks to Juho Nurminen of Mattermost who reported the error.
>
>This is CVE-2022-24675 and https://go.dev/issue/51853.
>
>
>- crypto/elliptic: tolerate all oversized scalars in generic P-256
>
>A crafted scalar input longer than 32 bytes can cause 
>P256().ScalarMult or P256().ScalarBaseMult to panic. Indirect uses through 
>crypto/ecdsa and crypto/tls are unaffected. amd64, arm64, ppc64le, and 
>s390x are unaffected.
>
>This was discovered thanks to a Project Wycheproof test vector.
>
>This is CVE-2022-28327 and https://go.dev/issue/52075.
>
>
>- crypto/x509: non-compliant certificates can cause a panic in Verify 
>on macOS in Go 1.18
>
>Verifying certificate chains containing certificates which are not 
>compliant with RFC 5280 causes Certificate.Verify to panic on macOS.
>
>These chains can be delivered through TLS and can cause a crypto/tls 
>or net/http client to crash.
>
>Thanks to Tailscale for doing weird things and finding this.
>
>This is CVE-2022-27536 and https://go.dev/issue/51759.
>
>
> View the release notes for more information:
> https://go.dev/doc/devel/release#go1.18.minor
>
> You can download binary and source distributions from the Go web site:
> https://go.dev/dl/
>
> macOS binary artifacts for Go 1.18.1 are not available at this time due to 
> an issue <https://go.dev/issue/52317>.
> We are working on providing them as soon as possible. Sorry for the 
> inconvenience.
>
> To compile from source using a Git clone, update to the release with
> "git checkout go1.18.1" and build as usual.
>
> Thanks to everyone who contributed to the releases.
>
> Cheers,
> Dmitri and Cherry 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/0fe07807-da65-4e3e-86ce-b5df14417d59n%40googlegroups.com.

[go-nuts] Re: Handle 1 million concurrent connections with 50 lines Go code

[Amnon]

Yes, the Go runtime does use epoll internally and schedules gorountines 
when their data is available. 
See 
https://github.com/golang/go/blob/17b2fb1b656a275906b5071c562439d50a27f167/src/runtime/netpoll_epoll.go
It does scale nicely and can handle tens of thousands or even hundreds of 
thousands of concurrent connections, without the "Thundering 
Herd" type behaviour which one would expect from such systems.
I have not tried it with millions of connection, but if you are interested, 
then run a test, but the consume side of your test will run out of ports.

On Wednesday, 6 April 2022 at 14:43:16 UTC+1 Jack Li wrote:

> Hi group,
>
> I am going through this page: https://studygolang.com/articles/22820 , It 
> claims that the 50 lines of Go code handles 1 million concurrent 
> connections from network clients, on 1 single server machine with a 4-Core 
> CPU and 16G memory.
>
> Does the package net already utilize IO Multiplexing internally, like 
> epoll (epoll_create, epoll_ctl, epoll_wait)? So I can just use package net 
> and gain the epoll ability automatically without calling epoll apis 
> manually in Go?
>
> Thanks
>
> Server:
> ```
> package main
>
> import (
> "fmt"
> "net"
> "os"
> "time"
> )
>
> var array []byte = make([]byte, 10)
>
> func checkError(err error, info string) (res bool) {
>
> if err != nil {
> fmt.Println(info + "  " + err.Error())
> return false
> }
> return true
> }
>
> func Handler(conn net.Conn) {
> for {
> _, err := conn.Write(array)
> if err != nil {
> return
> }
> time.Sleep(10 * time.Second)
> }
> }
>
> func main() {
>
> for i := 0; i < 10; i += 1 {
> array[i] = 'a'
> }
>
> service := ":"
> tcpAddr, _ := net.ResolveTCPAddr("tcp4", service)
> l, _ := net.ListenTCP("tcp", tcpAddr)
>
> for {
> conn, err := l.Accept()
> if err != nil {
> fmt.Printf("accept error, err=%s\n", err.Error())
> os.Exit(1)
> }
> go Handler(conn)
> }
>
> }
> ```
>
> Client:
>
> ```
> package main
>
> import (
> "flag"
> "fmt"
> "net"
> "os"
> "time"
> )
>
> var RemoteAddr *string
> var ConcurNum *int
> var LocalAddr *string
>
> func init() {
> RemoteAddr = flag.String("remote-ip", "127.0.0.1", "ip addr of remote 
> server")
> ConcurNum = flag.Int("concurrent-num", 100, "concurrent number of 
> client")
> LocalAddr = flag.String("local-ip", "0.0.0.0", "ip addr of remote 
> server")
> }
>
> func consume() {
>
> laddr := {IP: net.ParseIP(*LocalAddr)}
>
> var dialer net.Dialer
> dialer.LocalAddr = laddr
>
> conn, err := dialer.Dial("tcp", *RemoteAddr+":")
> if err != nil {
> fmt.Println("dial failed:", err)
> os.Exit(1)
> }
> defer conn.Close()
>
> buffer := make([]byte, 512)
>
> for {
> _, err2 := conn.Read(buffer)
> if err2 != nil {
> fmt.Println("Read failed:", err2)
> return
> }
>
> //  fmt.Println("count:", n, "msg:", string(buffer))
>
> }
>
> }
>
> func main() {
> flag.Parse()
> for i := 0; i < *ConcurNum; i++ {
> go consume()
> }
> time.Sleep(3600 * time.Second)
> }
> ```
>

-- 
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/e139c771-4b11-49c6-9045-ed65c861ded2n%40googlegroups.com.

[go-nuts] Re: Convert string to time.Duration

[Amnon]

Use time.ParseDuration()

https://go.dev/play/p/SWUHBiSpflh

On Sunday, 3 April 2022 at 23:48:54 UTC+1 vika...@gmail.com wrote:

> I am looking to convert a *string* (say 4) to type *time.Duration*.
>
> I've looked around but could not find a way to do so.
>
> // https://go.dev/play/p/EUuDAY-Qx8N
> package main
>
> import (
> "fmt"
> "time"
> )
>
> func main() {
> // var addHours string = 4
> fmt.Println(time.Now().Local())
> timeAdd := time.Now().Local().Add(time.Hour * 4) // I want to use 4 
> from a string variable here
> fmt.Println(timeAdd)
> }
>

-- 
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/f09becd3-c67d-4b13-b61d-d9ca1c8ae894n%40googlegroups.com.

[go-nuts] Type Hints for Golang

[Amnon]

Python has had Type Hints since 2014 (see PEP 484).

Isn't it time the Golang Language caught up?

I mean, it is 2022
 - or to be more precise April 1st 2022...

-- 
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/785ce28b-0bdd-46e0-adfd-94d9c8156ba4n%40googlegroups.com.

[go-nuts] Re: Is it possible to change the existing printline dynamically in golang?

[Amnon]

Yes, this is the murky world of ANSI escape codes.
Fortunately there are a whole load of libraries which do this for you...
Try https://github.com/cheggaaa/pb
or https://github.com/schollz/progressbar
or github.com/vardius/progress-go


On Friday, 1 April 2022 at 13:12:11 UTC+1 yan.z...@gmail.com wrote:

> Got it:
>
> package main
>
> import(
> "fmt"
> "time"
> )
>
> func main() {
>   fmt.Printf("Hello")
>   time.Sleep(time.Second)
>   time.Sleep(time.Second)
>   fmt.Printf("\r")
>   fmt.Printf("World\n")
> }
>
> 在2022年4月1日星期五 UTC+8 15:34:08 写道：
>
>> You can use the ansi escape code if the target terminal supports it. 
>> Alternatively, you can use the carriage return '\r' and reprint the line. 
>> Note you may need to overwrite with empty space to delete the line before 
>> rewriting it.
>>
>> On Friday, April 1, 2022 at 12:38:37 PM UTC+7 yan.z...@gmail.com wrote:
>>
>>> I just noticed how python pip upgraded from printing numerous process 
>>> bars like this:
>>> ■■■   30% completed
>>>  40% completed
>>> ■■60% completed
>>>    80% completed
>>> ■■  100% completed
>>>
>>> to a single line of a growing bar and changing declaration.
>>>
>>> It is definitely a functionality that  prompts of both Linux and Windows 
>>> allows -
>>> To change the previous print line.
>>> Is it possible to realize this in golang?
>>>
>>>   Zhaoxun
>>>
>>

-- 
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/47ad2497-6a3a-4aae-9559-5f3fd0bac808n%40googlegroups.com.

[go-nuts] debug.ReadBuildInfo is info.Main.Version always "(devel)"

[Amnon]

I was hoping to use debug.ReadBuildInfo to avoid using ugly --ldflags -X 
directives to insert the current git version into my runtime. This works as 
expected for dependencies. But the main module comes out as (devel). Is 
there a way to use ReadBuildInfo to get the actual tag and has of the main 
module?

-- 
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/ec68fae5-c7c7-4906-ac08-767a41eaf68en%40googlegroups.com.

Re: [go-nuts] Re: New edition of the Go Programming Language comming soon ?

[Amnon BC]

Great post, Rob!
CS people generally write books for people like themselves and find it hard
to
put themselves in the position of someone without a CS degree, learning
their first programming language.
A lot of people are aware of the lack of good beginner material, but few
people have the experience
in teaching beginners needed to write it. So great that you are taking
steps to rectify this.
Best of luck with the book! I will certainly be ordering a copy when it
comes out.




On Tue, Mar 15, 2022 at 4:59 AM Rob Muhlestein  wrote:

> The essential issue is that there are a number of resources for people
> "with prior programming experience" and literally none for people learning
> Go as a first language. I find this to be very unfortunate because so much
> of Go promotes solid programming practices that could significantly impact
> beginners for the rest of their coding lives (goroutines instead of
> promises, for example). Instead, the community seems content with simply
> suggesting beginners "learn another language first" and I've accepted that.
> I just find it a real loss of an excellent opportunity.
>
> The rest of this is just me blabbing on about helping beginners. 
>
> And I'm sorry, that book is anything but clear. In my experience, the
> people who say such things also say that K C is "clear." It's a matter of
> opinion and audience, and if you are a Ph.D in computer science with C
> coding under your belt, hell yeah, it's *very* clear. I just work with
> beginners with no CS experience a lot and they balk at the irrelevant
> examples, unnecessary bombastic voice, and excessive assumptions. I'm
> sincerely glad some do find it valuable.
>
> By the way, why doesn't our community promote more top-of-the-line, free
> resources over paid books that become immediately out of date? With all the
> money being dumped into "universities" and "free training" of late from
> different corporations facing the doubt of good IT talent I want to believe
> a dedicated team focused specifically on helping beginners adopt Go is a
> possibility --- especially given the critical dependency on Go in all of
> cloud native computing. Being able to read Go source (minimally) should be
> mandatory learning for any infrastructure engineer these days. I've solved
> so many problems simply from reading the K8S or Helm source rather than the
> docs.
>
> I get the impression so many are so busy doing amazing things *with* Go
> that there is very little energy left to do things to help others start,
> and by others I don't mean those paying for corporate training. I mean
> those capable of learning but with limited means; I mean the AP CS programs
> that are still mandating mastering of single OOP inheritance that
> completely neglect concurrent programming practices; I mean self-taught
> upskillers learning to write their own Kubernetes operators. Go could
> easily displace Java as the best AP CS language if more attention were
> given to these considerations.
>
> The Tour of Go is only about 60% finished according to the project
> milestones in the source of the project. And who thought throwing bitwise
> operators in the first chapter (or so) was a good idea?
>
> It just seems like people are content letting beginners fend for
> themselves, which is fine for most, but not for the vast majority of people
> for whom Go is supposedly created. This is the reason I regularly receive
> feedback about Go from the many I've helped who say, "Go just isn't
> beginner friendly" and I'm tired of them saying that "Rust is more
> welcoming" (which is just so untrue).
>
> I know I'm droning on, but someone has to bring this up. Go *is* for
> beginners. We just need help convince people, and frankly that starts with
> being able to make a simple, solid book/resource recommendation for
> beginners. There's just nothing out there. I've read 'em all. There are
> literally no books that cover even 1.17 for beginners. (Modules were one of
> the worst things to happen to beginners and we are finally getting on with
> a simpler future.) With Go 1.18 we have a real opportunity to correct this.
>
> For the record, I'm slowly putting together enough material to
> crowd-source a beginner Go 1.18 book and have probably a few dozen people
> interested in helping, but like so many others, I have other stuff I'm
> first required to focus on. Look forward to anything I can do to help.
>
> Thank you.
>
> ---
> Rob Muhlestein
> r...@rwx.gg
> https://twitch.tv/rwxrob
>
> --- Original Message ---
>
> On Monday, March 14th, 2022 at 1:06 PM, Steve Mynott <
> steve.myn...@gmail.com> wrote:
>
> > My experience with this book has been different. I thought it was
> >
> > superb -- a masterpiece of clarity.
> >
> > I don't think it's intended for absolute beginners to programming but
> >
> > it's great for people with prior programming experience.
> >
> > It seems to me unlikely there isn't a suitable absolute beginners book
> >
> > available from 

Re: [go-nuts] Is there a way to specify or use the tmp directory used in testing?

[Amnon]

Use t.TestDir()
https://pkg.go.dev/testing#T.TempDir
On Wednesday, 23 February 2022 at 14:37:54 UTC mlevi...@gmail.com wrote:

> Use absolute paths? Feels like you're trying to bend something very hard 
> here
>
> On Wed, Feb 23, 2022 at 2:54 PM Leam Hall  wrote:
>
>> My program uses data and template files located relative to the binary. 
>> Since go test creates the binary under test in /tmp/go-build., there 
>> are no data or template files. How do I either specify what directory to 
>> build in so I can create the files, or get the tmp directory name before 
>> the tests are run so I can write files to it?
>>
>> Thanks!
>>
>> Leam
>>
>> -- 
>> Site Automation Engineer   (reuel.net/resume)
>> Scribe: The Domici War (domiciwar.net)
>> General Ne'er-do-well  (github.com/LeamHall)
>>
>> -- 
>> 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/7d8cf3dc-14ab-315f-ce5a-9e3cca877e17%40gmail.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/75b9fadf-b208-4eaa-a3ec-7faa6585d0dbn%40googlegroups.com.

[go-nuts] Re: New edition of the Go Programming Language comming soon ?

[Amnon]

I have not heard of any plans to bring out a new edition of the book.
But the original 2015 edition is timeless, as it deals with the fundamentals
of the language, of why things are the way they are. Yes they have been some
additions to the language since 2015, but nothing which invalidates 
anything in the book.
All the examples still run and will continue to run under future versions 
of Go.
I would say: just buy it. Your money will not be wasted.

On Sunday, 13 February 2022 at 11:22:47 UTC christoph...@gmail.com wrote:

> Hello Go friends, 
>
> is there a new edition of the "Go Programming Language" book to be 
> published soon ? 
> It is quite old now and there have been a few changes to Go since then. 
> Go.mod and generics. I was considering buying it, but if a new edition 
> comes out in a few months, it would be wasted money. 
>

-- 
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/24efa60f-91a3-4831-8f21-9b1e63b02379n%40googlegroups.com.

[go-nuts] Re: Web development with Go

[Amnon]

Applications whether single page or multiple pages do need to communicate 
with some sort 
of back-end to get their data and perform business logic. They need 
something to serve their AJAX requests.
And Go is a useful language for writing such  back-ends.

On Monday, 7 February 2022 at 07:54:38 UTC merson...@actmedical.com.au 
wrote:

> Of course, Brian.
> I meant the CA Certificates. 
> Merson
>
> On Saturday, February 5, 2022 at 8:11:49 PM UTC+11 Brian Candler wrote:
>
>> On Saturday, 5 February 2022 at 00:05:18 UTC merson...@actmedical.com.au 
>> wrote:
>>
>>> the same app
>>> rewritten in Go reduces the size by a huge amount as the only thing you 
>>> need to include in a scratch base image is the binary plus
>>> some certificates.
>>>
>>
>> I wouldn't put certificates into a container image either, and definitely 
>> not the related private keys.  I'd store them as kubernetes Secrets and 
>> provide them to the container that way.  It reduces the exposure of the 
>> private keys, and allows certificates to be replaced without rebuilding the 
>> image - e.g. to deploy the same container in two different places.
>>
>

-- 
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/2db6f575-699a-4497-b1e2-8153d208c848n%40googlegroups.com.

Re: [go-nuts] Slices of pointers or not?

[Amnon]

Go runtime is dominated by the costs of allocation and GC.

If you return 1 persons, then if we make the (unrealistic) assumption 
that a Person contains not pointers (strings etc). then returning []Person 
would require one allocation, whereas returning []*Person would require 
10,001. And GC will be much slower as there will be 10,000 more objects to 
mark.
Iteration across the returned slice will also be much faster in the former 
case, as each Person will 
reside in (cache friendly) sequential memory locations, whereas in the 
latter case the memory location
of each person will be effectively randomised and entail a cache miss.

So in general returning []Person will be much faster. 
Of course you should make sure you pre-allocate the entire slice, rather 
than letting it grow automatically
as the result of appends.


On Friday, 4 February 2022 at 09:43:28 UTC pauloaf...@gmail.com wrote:

> I appreciate your help.
>
> Em sexta-feira, 4 de fevereiro de 2022 às 00:12:47 UTC-3, 
> ren...@ix.netcom.com escreveu:
>
>> I think the OPs question was specifically about the cost of returning 
>> from a function - it is the same. 
>>
>> > On Feb 3, 2022, at 8:03 PM, Connor Kuehl  wrote: 
>> > 
>> > On Thu, Feb 3, 2022 at 7:07 PM Paulo Júnior  
>> wrote: 
>> >> 
>> >> Hi all. 
>> >> 
>> >> I hope you are well. 
>> >> 
>> >> Is there a big difference, in terms of performance or functionality, 
>> between declaring []*Person or []Person as a return type of a function? 
>> > 
>> > If you find yourself iterating over a group of structs like this a lot 
>> > (especially if there's a lot of them to iterate over), you might want 
>> > to consider measuring the performance differences between []*Person or 
>> > []Person. With pointers, the actual structs might be far away from 
>> > each other in memory, which may prevent you from taking full advantage 
>> > of your processor's cache since it won't be able to benefit from the 
>> > spatial locality that an array (or slice) offers. 
>> > 
>> > Connor 
>> > 
>> > -- 
>> > 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/CAC_QXZS-QEKTgvsK3TKk-yUyc1jP81HngHz6dcDV8bZwqLBT6Q%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/1f76f2e2-a26a-4f05-bb5a-435f98a93219n%40googlegroups.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Amnon BC]

> From the tests that I have performed, I can see that a Ticker pretty
accurately fires at every 1ms interval.

It will depend on the load on your machine. As the load on the machine
increases, so with the jitter in the tick time.

On Thu, Feb 3, 2022 at 1:19 AM Robert Engels  wrote:

> I am unclear why you need to use an N of M. I would make sure the hardest
> case is handled and you can use a variety of techniques to partition the
> work.
>
> On Feb 2, 2022, at 6:58 PM, envee  wrote:
>
> And I forgot to mention that approach I mentioned talks about waking up N
> goroutines at a time. The way I plan to do is to select a range of N
> goroutines from my list of goroutines and only allow those goroutines to
> send HTTP requests.
> I could use this approach to select the N goroutines or even use a
> Semaphore. I presume using a Semaphore, will allow a good amount of random
> N goroutines out of M goroutines to execute.
>
> On Thursday, 3 February 2022 at 10:26:28 UTC+11 envee wrote:
>
>> Thanks Robert, Uli and Ian for your suggestions.
>>
>> I think what I will probably do is use a Ticker with a duration of 1ms.
>> At every 1ms, I will "wake-up" N number of goroutines to trigger HTTP
>> requests.
>> That number N = (request rate per second / 1000)  = requests per ms.
>> So, if I need to ensure a rate of 1 requests per second, I believe it
>> should be possible for the Ticker to return after every 1ms and then fire
>> about 10 requests at every such interval.
>> From the tests that I have performed, I can see that a Ticker pretty
>> accurately fires at every 1ms interval.
>> I think it's only when the Ticker duration falls below 1ms, that I see
>> issues.
>>
>> If my desired rate is less than 1000 per second, then I will create a
>> Ticker to return every 1000/request rate milliseconds, which will be a
>> number greater than 1ms.
>>
>> This approach is closely based on Robert's suggestion about using a
>> higher duration for Ticker time and waking up a small subset of goroutines.
>>
>> I think it should be ok for a client to be accurate at the level of
>> granularity of 1ms.
>>
>>
>> On Thursday, 3 February 2022 at 01:14:20 UTC+11 ren...@ix.netcom.com
>> wrote:
>>
>>> Because 2 is a magnitude larger than 2000.
>>>
>>> > On Feb 1, 2022, at 1:44 PM, Uli Kunitz  wrote:
>>> >
>>>
>> --
> 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/209b18aa-1317-4d72-80a1-222f10a26013n%40googlegroups.com
> 
> .
>
> --
> 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/3GUnjdoWjqU/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/F912EE7E-4F80-4C16-ABC1-943572FD576C%40ix.netcom.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/CALg-z3VpSw1dJwbn4YDd98qJsfj_NtSDJUrsA3p2xk%2BzQMChuQ%40mail.gmail.com.

Re: [go-nuts] Re: Why, oh why, do people do this? Things that annoy me in Go code.

[Amnon]

Idiomatic naming in Go is one of the hardest things to communicate.
Everyone seems to bring the idioms from previous languages. Dave Cheney 
writes about 
"Lengthy bureaucratic names carry a low amount of signal compared to their 
weight on the page".
Identifiers are not sentences or stand alone stories. They are the the 
basic building blocks for our code.
We have all seen code infected by these names - long names leading to long 
lines of code,
and verbose walls of dense text, repetitive and hard to read.

I always encourage people to read https://go.dev/doc/effective_go#names
to study the Go standard library, and develop a feel of what Go code should 
read like.


>
>

-- 
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/2cd93f81-9ae1-4e49-890c-b2d383955febn%40googlegroups.com.

Re: [go-nuts] Issues when using time.Ticker microsecond duration

[Amnon]

Irrespective of the language, these sort of delays are always at the mercy 
of the scheduling jitter of the underlying operating system.
The operating system is at liberty to preempt any application at any time, 
and then resume it some arbitrary time later. If you ask the OS to sleep 
for 
1ms, the OS will deschedule the process, and then resume at some point in 
time after 1ms. Exactly how long after depends 
on what else is running on the processor, contention for cores etc. Once 
the process gets to run again, the Go runtime 
does its own scheduling, it may have many more goroutines ready to run than 
it has available OS threads. So the gorountine which 
is waiting on the ticker could wait an arbitrary amount of time beyond the 
minimum 1ms delay.

The demand for all delays to be within 5% of 1ms is hard to achieve in any 
language running on top of a general purpose (non-realtime) OS,  and is 
double hard in Go which adds an additional layer of scheduling.

A better approach would be to start with a 1ms ticker, but then at each 
tick calculate the amount of time which has actually elapsed, and then send 
the required number of requests to catch-up with the required request rate. 
This will mean a slightly uneven and jittery request rate at the 
microscopic level, and the amount of jitter will be affected by how heavily 
loaded the machine is. But the request rate will even out when looking over 
longer time periods. This will be the best you can do in Go, or in 
user-space in any language running on a non-real-time OS. 


On Monday, 31 January 2022 at 13:50:35 UTC ren...@ix.netcom.com wrote:

> Sorry for typos. Early morning on small phone with no coffee and old 
> person eyes. :)
>
> On Jan 31, 2022, at 7:13 AM, Robert Engels  wrote:
>
> 
>
> If you need a “guarantee” in these efforts it is much more complex. You 
> must likely need a real-time OS and interrupt driven code. A general 
> purpose language, os and hardware probably won’t cut it. 
>
> This of it this way though, if you had 20 cpus to spread the work on, you 
> only need to interrupt every 10 ms - far more achievable. As long as the 
> work is independent. 
>
> On Jan 30, 2022, at 11:10 PM, envee  wrote:
>
> Thanks Kurtis and Robert.
>
> My use-case is for a telecommunications application (HTTP/2 client, 5G 
> client to be precise) which needs to send 5G (HTTP/2) requests to a server 
> at a configurable rate (TPS). 
> While the telecom industry very commonly use the word TPS (Transactions 
> Per Second), I would like to control the rate within the second i.e. if the 
> TPS is to be 2000, then I would like to spread these 2000 transactions 
> (HTTP/2 requests) over 1 second uniformly i.e. 1 request every 500 
> mico-seconds which will then result in 2000 requests in that 1 second.
> I believed that by using a time.Ticker to fire every 500 micro-seconds, I 
> would be able to achieve this outcome.
>
> Is there any other way you could suggest I do this using Go ? 
>
> On Monday, 31 January 2022 at 15:17:23 UTC+11 ren...@ix.netcom.com wrote:
>
>> Pretty much what Kurtis said. Low interval timers usually require 
>> specialized constructs if not a real time OS to efficiently (or even at 
>> all). 
>>
>> On Jan 30, 2022, at 9:16 PM, envee  wrote:
>>
>> Thanks, but I am not sure how that reference solves the issue ?
>>
>> Or are you suggesting that the only way is to use Cgo and invoke usleep 
>> to get very close to the Ticker duration specified ?
>>
>> On Monday, 31 January 2022 at 11:25:58 UTC+11 ren...@ix.netcom.com wrote:
>>
>>> See https://github.com/golang/go/issues/27707
>>>
>>> On Jan 30, 2022, at 5:50 PM, envee  wrote:
>>>
>>> Hi All,
>>>
>>> I understand this issue has been discussed in the past, and I have seen 
>>> a few comments from Ian and Russ Cox about this topic, but I could not 
>>> arrive at a conclusion about how I can make the time.Ticker send me ticks 
>>> at atleast close to the Ticker duration I specify. At the moment, I am 
>>> seeing ticks being sent at way over the specified duration especially when 
>>> I have sub-millisecond durations. 
>>> With 1ms duration, the ticker seems to be quite close to the duration 
>>> (maybe within +/-5%). I would be happier if it were within 1%, but I can 
>>> handle that.
>>>
>>> With 1 micro-second duration, the ticker sends ticks nearly 4 times 
>>> slower than expected.
>>>
>>> Here is my sample code
>>> "
>>> ti := time.NewTicker(1 * time.Millisecond)
>>> start := time.Now()
>>> for i := 0; i < 1000; i++ {
>>> <-ti.C
>>> }
>>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>>> "
>>>
>>> The output is usually close to 1 second as expected (close to) when 
>>> using 1ms duration.
>>> elapsed time = 1.000159338s
>>>
>>>
>>> My code for the microsecond test is :
>>> "
>>> ti := time.NewTicker(1 * time.Microsecond)
>>> start := time.Now()
>>> for i := 0; i < 100; i++ {
>>> <-ti.C
>>> }
>>> fmt.Printf("elapsed time = %v\n", time.Since(start))
>>> "
>>>
>>> With this, I 

Re: [go-nuts] Why, oh why, do people do this? Things that annoy me in Go code.

[Amnon]

Indeed.

There are quite a few linters out there which object to good idiomatic code 
and 
which would fail the Go Standard Library.

And too many people are happy to pollute their codebase with extraneous 
noise,
rather than fixing the linters, or using just using high quality linters 
(such as go vet, and staticcheck).

On Friday, 10 December 2021 at 07:21:56 UTC Jason E. Aten wrote:

> 6 is probably because of the linters that complain if you don't.
>
>
>>
>>
>> 6) Code where almost every line prefixed by `_, _ =`
>> and the underscores won't go away when you wipe your screen
>>
>>
>>
>>

-- 
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/6ef1803d-2d35-4962-ac72-a263f2effaabn%40googlegroups.com.

[go-nuts] Why, oh why, do people do this? Things that annoy me in Go code.

[Amnon]

1) Long functions that go on forever and contain long lambdas and 8 levels 
of indentation.

2) Long variable names.

3) Variable names which include the type of the variable.

4) Packages whose name contain the word '/pkg/'

5) Repos which contain the prefix go-

6) Code where almost every line prefixed by `_, _ =`
and the underscores won't go away when you wipe your screen


-- 
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/d367f41a-53e8-415e-a44c-1ace051359d3n%40googlegroups.com.

[go-nuts] Re: Does Location of Variable Declarations Matter?

[Amnon]

In K C back in the 1970s, you had to declare your local variables at the 
beginning of a function, before any statements.
I think this is the source of the habit of declaring your variables first.

Readability is key here. So it makes sense to declare a statement close to 
where it is first used,
and limit it to the smallest possible scope where it is needed.


On Sunday, 28 November 2021 at 17:33:43 UTC jlfo...@berkeley.edu wrote:

> Some people put all their variable declarations at the beginning of a 
> function.
> Others put them at various places in a function, where the variables are 
> used.
>
> I've always wondered if a variable declaration results in any runtime 
> overhead.
> One obvious concern is what happens if a variable declaration is inside a 
> loop.
>
> Cordially,
> Jon Forrest
>
>
>

-- 
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/2734fbdf-ee96-49cb-8666-69c1ac775624n%40googlegroups.com.

[go-nuts] Re: Mocking requests in Go

[Amnon]

Nice post. Good advice.

On Friday, 5 November 2021 at 17:08:25 UTC bke...@zushealth.com wrote:

> Sharing an interesting post by Zus  technologist 
> Sonya Huang on mocking requests in Go:
>
> https://www.linkedin.com/feed/update/urn:li:activity:6862376852103798784/
>

-- 
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/ced672ee-5aa4-42e8-8a39-0336767a7539n%40googlegroups.com.

[go-nuts] Re: Help getting database/sql pooling merged

[Amnon]

try pinging https://groups.google.com/g/golang-dev

On Friday, 29 October 2021 at 23:37:13 UTC+1 Steven Hartland wrote:

> Just a quick bump to see if we can get this over the line in time for the 
> 1.18 release freeze in just a couple of days time?
>
> On Sat, 23 Oct 2021 at 00:29, Steven Hartland  
> wrote:
>
>> There's been a long standing bug 
>>  in database/sql pooling 
>> which means SetConnMaxIdleTime doesn't work.
>>
>> I found and fixed the bug 
>>  back in June of 2020, 
>> but have so far been unable to get this relatively simple fix across the 
>> line.
>>
>> With 1.18 freeze fast approaching, I'd love to get this merged before 
>> then so we can have working DB pooling without having to run a patched core 
>> library.
>>
>> Others have looked at it in the past and said the fix looks good, and 
>> we've been running it for well over a year now, so I would say confidence 
>> is high ;-)
>>
>> So any help to get it merged would be most appreciated!
>>
>>Regards
>>Steve
>>
>

-- 
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/2d0b8eca-0501-4641-9345-4a075b463048n%40googlegroups.com.

Re: [go-nuts] Re: How to negotiate authentication over HTTP ? (the Go way)

[Amnon]

The design of the client side of net/http is not great 
, and 
requires a lot of boilerplate.

I don't know of any approach which is better than your 
DoHTTPRequestWithAuthenticationHandling (though I would have 
chosen a very much shorter name). 

Every request to a service  would normally require payload serialisation, 
authentication, error handling, response code checking,
and response unmarshalling. I normally encapsulate all of these in a single 
method which is called by the functions which are used to 
call the endpoints. 

I think it is generally accepted that the net/http needs some love, from 
the client point of view.
But it is solid and well tested. We have got used to its quirks and have 
learned to live with it, and nobody has yet come up with a compelling 
alternative.

Perhaps we should try to convince Kenneth Reitz to switch to Go?




On Wednesday, 27 October 2021 at 00:23:01 UTC+1 ben...@gmail.com wrote:

> Ah, thanks for that info -- glad somebody is reading the docs ... :-) 
> Seems like you're well ahead of me here. I'd be interested to hear what 
> others have done, or what you end up with. -Ben
>
> On Wed, Oct 27, 2021 at 12:18 PM mi...@ubo.ro  wrote:
>
>> That would work great but the documentation on RoundTriper specifically 
>> forbids it[0]. Unless I get it wrong(do I?) you are not allowed to read the 
>> response within RoundTrip. The request needs to be .Clone-ed as well but 
>> that's not an issue.
>>
>>
>> [0] https://pkg.go.dev/net/http#RoundTripper  
>> // RoundTrip should not attempt to interpret the response. In 
>> // particular, RoundTrip must return err == nil if it obtained
>> // a response, regardless of the response's HTTP status code. 
>> // A non-nil err should be reserved for failure to obtain a
>> // response. Similarly, RoundTrip should not attempt to
>> // handle higher-level protocol details such as redirects, 
>> // authentication, or cookies.
>> // RoundTrip should not modify the request
>>
>>
>>
>>
>> *On 27/10/2021 02:09, Ben Hoyt wrote:*
>> *Oh, I see. An "ExecuteHTTP" function seems reasonable, but yeah, if you 
>> need an *http.Client, I think you have to customize the 
>> Transport/Roundtripper. You mention in your initial email that RoundTripper 
>> "forbids you from even reading the response headers", but I don't think 
>> that's the case, right?*
>>
>> *For example, here's a custom "AuthTransport":*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *type AuthTransport struct { AuthHeader string}func (t 
>> *AuthTransport) RoundTrip(request *http.Request) (*http.Response, error) 
>> { request.Header.Set("X-My-Auth", t.AuthHeader) response, err := 
>> http.DefaultTransport.RoundTrip(request) if err != nil { return 
>> nil, err } if response.StatusCode == 403 || 
>> response.Header.Get("WWW-Authenticate") != "" { fmt.Println("Would 
>> retry here") }return response, nil}*
>>
>> *and then you'd instantiate your http.Client like so:*
>>
>>
>>
>>
>> *client := {Timeout:   5 * time.Second,Transport: 
>> {AuthHeader: "abcd1234"},}*
>>
>> *Did that not work for you?*
>>
>>
>> *-Ben*
>>
>>
>>
>> On Wednesday, October 27, 2021 at 1:52:18 AM UTC+3 mi...@ubo.ro wrote:
>>
>>> Thanks for your help. I'm aware I can set the headers that way but the 
>>> authentication transport also needs to inspect the response headers and 
>>> optionally re-submit the request based on the headers received. That's part 
>>> of the "negotiation" mechanism. That's because we don;t know what 
>>> authentication scheme is supported by the remote party until we receive the 
>>> actual response/headers from a blind request. 
>>>
>>> Below is a simple use case:
>>>
>>>   - the http client executes a reques with no authentication.
>>>
>>>   - we receive a status code 403 along with a www-header indicating that 
>>> oauth2 authentication is supported. 
>>>
>>>- we resend the request with appropriate oauth2 headers.
>>>
>>> Note that we had to read the response code and response headers so that 
>>> we can re-send the request.  This is the part that I wish I could automate 
>>> using the http.RoundTripper. 
>>>
>>>  The alternative is to either handle the response manually after each 
>>> request or create a custom endpoint < i.e. func ExecuteHTTP(*http.Client, 
>>> *http.Request)(*http.Response, error) >  that handles the response headers 
>>> and retries the requests using the proper authentication headers.
>>>
>>> In both cases you loose the flexibility to use a http client that does 
>>> all this in the background. 
>>>
>>> Some packages (i.e ElasticSearch package) support configuration using 
>>> your own http client. However you cannot pass a custom `ExecuteHTTP` 
>>> function to ElasticSearch so it becomes quite hard to hack the 
>>> authentication/negotiation.
>>>
>>> - Mihai.
>>>
>>> On Wednesday, October 27, 2021 at 1:32:24 AM UTC+3 ben...@gmail.com 
>>> 

[go-nuts] Re: memory usage through "json.NewDecoder(res.Body).Decode()"

[Amnon]

Sadly Decode does collect up the entire res.Body into memory.
See https://github.com/golang/go/issues/33714

On Tuesday, 26 October 2021 at 15:25:28 UTC+1 RS wrote:

> err = json.NewDecoder(res.Body).Decode()
> if err != nil {
> log.Println("ERROR:", err)
> return
> }
>
> Using json.newdecoder to decode the coming response body from client? 
> Here is also the issue of " loading the entire response in memory and 
> parsing it" is a matter?
> As I am not using a buffer to copy?
>
> Thanks
>

-- 
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/ab60d03f-b130-486d-8788-7a3b8581d06dn%40googlegroups.com.

Re: [go-nuts] Draining http response bodies

[Amnon]

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

// It is the caller's responsibility to
// close Body. The default HTTP client's Transport may not
// reuse HTTP/1.x "keep-alive" TCP connections if the Body is
// not read to completion and closed.



On Friday, 8 October 2021 at 13:42:36 UTC+1 frave...@gmail.com wrote:

> 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 https://play.golang.org/p/5JDWYbRe0lD
> > suggests that leaving unread data in the response body will prevent 
> > the connection being reused, and much slower performance.
> > 
> > The documentation https://pkg.go.dev/net/http states:
> > "The client must close the response body when finished with it:"
> > 
> > The following example does include a call to io.ReadAll(resp.Body) 
> > but it does not spell out whether there would be a performance penalty
> > for failing to read the entire body.
> > 
> > It would be good if the standard library documentation was a bit more 
> explicit here.
>
> I suspect a lot of this actually comes down to operating system level 
> handling of TCP sockets, which is something that it would be hard for the 
> docs to address other than maybe offering a warning that your OS *might* 
> not release the port for reuse if the body isn't fully drained.
>
> I could be wrong, though, there's half a chance it's really a GC thing 
> instead. I'd have to look at the source to be sure.
>
>
> - Dave
>
>

-- 
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/7bf34622-831e-4efc-9f1e-bc63d442779en%40googlegroups.com.

[go-nuts] Re: Draining http response bodies

[Amnon]

Added issue https://github.com/golang/go/issues/48860

On Thursday, 7 October 2021 at 08:36:25 UTC+1 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 https://play.golang.org/p/5JDWYbRe0lD
> suggests that leaving unread data in the response body will prevent 
> the connection being reused, and much slower performance.
>
> The documentation https://pkg.go.dev/net/http states:
>
> "The client must close the response body when finished with it:"
>
> The following example does include a call to io.ReadAll(resp.Body) 
> but it does not spell out whether there would be a performance penalty
> for failing to read the entire body.
>
> It would be good if the standard library documentation was a bit more 
> explicit here.
>
>

-- 
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/1169be3d-e5a5-4d15-aded-a7f795e5a25an%40googlegroups.com.

[go-nuts] Draining http response bodies

[Amnon]

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 https://play.golang.org/p/5JDWYbRe0lD
suggests that leaving unread data in the response body will prevent 
the connection being reused, and much slower performance.

The documentation https://pkg.go.dev/net/http states:

"The client must close the response body when finished with it:"

The following example does include a call to io.ReadAll(resp.Body) 
but it does not spell out whether there would be a performance penalty
for failing to read the entire body.

It would be good if the standard library documentation was a bit more 
explicit here.

-- 
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/14603faa-cf60-4547-9015-8ac14083fc54n%40googlegroups.com.

[go-nuts] Better documentation needed on draining http request bodies

[Amnon]

Is it necessary to drain 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 https://play.golang.org/p/5JDWYbRe0lD
suggests that leaving unread data in the response body will prevent 
the connection being reused, and much slower performance.

The documentation https://pkg.go.dev/net/http states:

The client must close the response body when finished with it:
But it is silent on the question of whether the client should consume the 
entire body.

It would be good if the standard library documentation was a bit more 
explicit here.

-- 
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/2a29b5dc-e785-420f-bf58-72fb47470ba4n%40googlegroups.com.

Re: [go-nuts] What is the total max size of embed content?

[Amnon]

A cloud DB looks like a great option here.
The cost/complication would be trivial compared to the cost/complication 
fixing the tool chain to handle enormous executables,
and of shipping these around.

On Tuesday, 21 September 2021 at 20:41:42 UTC+1 glen@gmail.com wrote:

> Hello Ian,
>
> Yes, I think it is time I explain the 'why' of my inquiries into this. :-)
>
> My use case is this: Go, with its fast startup, pretty fast execution and 
> pretty small memory footprint, as well as it's ability to deploy as a 
> single binary, makes it a great language for cloud function-as-a-service 
> (FAAS). 
>
> My specific FAAS use case is for static, read-only databases: I am looking 
> at embedding modest sized (few GB to 10s of GB) read-only databases in the 
> Go binary. 
>
> This makes it possible to avoid the cost/complication of either using a 
> cloud db, or storing the db in (in the case of AWS) on a file system like 
> EFS (NFS), which the lambda has to mount. The databases are only updated 
> every couple of months / yearly.
> This is perhaps rather an obscure use case, but one that I think a number 
> of people would want to take advantage of.
>
> >Note that such files are going to take a long time to create and will be 
> unwieldy to use.
> Agreed. On my older desktop (Dell 7010 Kubuntu 20.10 4core i5 16GM) it 
> takes 45s to compile a trivial Go program that embeds three 500GB files.
>
> Actually, this is no different from those who want the simplicity and cost 
> savings of serving an entire static web site from embedded files. The 
> primary difference is the scale.
>
> Thanks,
> Glen
>
>
> On Tuesday, September 21, 2021 at 1:28:12 PM UTC-4 Ian Lance Taylor wrote:
>
>> On Tue, Sep 21, 2021 at 6:23 AM Glen Newton  wrote: 
>> > 
>> > Looking at https://groups.google.com/g/golang-codereviews/c/xkHLQHidF5s 
>> and https://github.com/golang/go/issues/9862 and the code to which they 
>> refer, it seems to me that the limit is 2GB independent of platform (is 
>> this true?), as the linker is limited to 2e9. 
>> > Again, should have done more of my homework! :-) 
>> > 
>> > 
>> https://github.com/golang/go/blob/master/src/cmd/internal/obj/objfile.go#L305
>>  
>> > 
>> > // cutoff is the maximum data section size permitted by the linker 
>> > // (see issue #9862). const cutoff = 2e9 // 2 GB (or so; looks better 
>> in errors than 2^31) 
>> > const cutoff = 2e9 // 2 GB (or so; looks better in errors than 2^31) 
>> > 
>> > The comment indicates that this is a limit in the linker; is this a 
>> limit in the elf format? If No, could the linker et al be modified to 
>> accept larger static data? 
>>
>> You're right: it does look like cmd/link imposes a 2G total limit. 
>> This is not a limitation of the 64-bit ELF format. It should be 
>> possible to make it larger. 
>>
>> Note that such files are going to take a long time to create and will 
>> be unwieldy to use. While it should be possible to increase the size, 
>> I would not be surprised if you hit other limits fairly quickly. 
>>
>> 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/82c4c579-effc-4092-a736-8fa9ab45552en%40googlegroups.com.

[go-nuts] Excellent blog post from Filippo on legacy SSL brokenness and Go 1.17

[Amnon]

https://go.dev/blog/tls-cipher-suites

In case anyone has not seen it, Filippo has published a blog post which 
shows
how SSL Cypher Suite negotiation is fundamentally broken in the older TLS 
versions.

My understanding of the post is that to run a secure server on the 
internet, 
just make sure you are building with Go 1.17.1 (or whatever is the latest 
version),
you no longer need to specify choice of secure CipherSuites that you 
accept. 
Go's Crypto will just do the right thing, and as application developers we 
no longer
need to get involved in the details.
This supersedes the advice in Flippo's 2016 Cloudflare post on the subject,
(though setting sensible timeouts to mitigate DDOS attacks is still a good 
idea).

Have I understood this right?

-- 
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/11990199-b7b3-43cf-b134-cfb3fc93a3c6n%40googlegroups.com.

[go-nuts] Re: Logging libraries and standard library compatibility

[Amnon]

Yes, this is a massive pain.

The standard library's log.Logger is not an interface, despite ending in er.

If it was an interface, it would be easy for third party packages to 
implement it, and then it would 
be a lowest common denominator for any package where doing some logging 
could be useful.

Unfortunately it is too late to change this.

On Sunday, 29 August 2021 at 00:38:50 UTC+1 amits...@gmail.com wrote:

> Hi all, a huge disclaimer - I am not familiar with the design
> decisions and internal details of anything that follows. They are
> coming from the point of view of a consumer of the language and the
> ecosystem and also someone trying to write about these things for an
> audience.
>
> Say I have an application - a HTTP server, where I initialize a
> log.Logger as implemented by the standard library and then I inject
> that into the handler functions where they call the Printf() or the
> other methods to log stuff. Say I have also configured a middleware to
> log data for every request, once again using the Printf() and family
> functions.
>
> Now, I want to implement some levelled and/or structured logging. So,
> here's my expectation - I should just be able to update the initial
> code and everything else should not be changed. Of course, in due
> course of time, I will update those to take advantage of the actual
> functionality offered by those libraries - levelled logging,
> structured logging. But, initially, my code should just build and
> work. Many years back, that's how I really found
> https://github.com/sirupsen/logrus useful and exciting. However, some
> more performant and recent packages don't seem to have that
> compatibility as a goal. For example, https://github.com/uber-go/zap
> doesn't AFAICT implement the Printf() or other functions. However,
> https://github.com/rs/zerolog does, which is great.
>
> I imagine this possibly is due to the standard library not exporting
> publicly available types for - logging handlers, formatters (encoders)
> and such that third party packages have difficulty implementing these
> in standard library compatible way?
>
> To summarize, I would have really wanted a way to avoid my code
> becoming tightly coupled with the logging library I am using but that
> seems to be hard at this stage.
>
> What does the community think?
>

-- 
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/9324158e-cb8b-46fc-91c3-f3d64ef27406n%40googlegroups.com.

Re: [go-nuts] Re: Makefiles for Go Programs

[Amnon]

I think the basic idea is that Go projects do not have makefiles because 
they do not need makefiles.
Ideally the Go command does the right thing, including fetching and 
building dependencies, and building 
entire trees of projects. Go is opinionated, and dictates where each 
package can be found on the filesystem.
Having a fixed convention means that configuration is not necessary. And 
the Go command usually does this 
better than hacked together make-files. The dependency analysis and object 
caching just work, so we don't 
spend our lives running `make clean; make distclean; make cleanall; make 
archconfig; make` 
each time our build fails to pick up the latest changes.

In the real world we do need to build docker images, and non-Go artifacts, 
so we do often have to fall back on some
sort of Makefile. But it is refreshing not to having each time to re-invent 
how to build a project spanning multiple directories.

On Monday, 23 August 2021 at 18:58:21 UTC+1 frave...@gmail.com wrote:

> On Aug 23, 2021, at 12:48, Roland Müller  wrote:
>
>
> What are the alternatives to Makefile that are used by Go developers? 
> Please comment :-)
>
>
> Well, there’s mage, which aims to more or less replace the functionality 
> of Make for Go. I’m not really sold on *needing* a replacement for Make, 
> and if you’re doing CI builds, it still adds an external dependency, but it 
> is an interesting project: https://magefile.org/
>
> I know Make from old C/C++ times. Therefore, my picture is that it is not 
> very portable and requires for quite many operations the usage of external 
> tools that again differ between the platforms. Basically Makefiles are 
> somehow enhanced shell scripts (Linux/Unix) or batch files (Windows).
>
>
> Makefiles are quite portable, at least assuming you’re using GNU Make 
> (which is at least available nearly everywhere). It may not be the most 
> ideal option with Windows, but nearly everywhere else it’s pretty solid.
>
> If you have problems with external tools behaving differently across 
> platforms (the behavior of “which” on Solaris vs. Linux or BSD being a 
> particular sticking point I’ve run across in scripts), I would argue that 
> there’s not much out there that’s going to solve that problem.
>
> Currently, at work I deal a lot with Maven, that is a bit too Java 
> -oriented in spite of being capable in principle to build and compile other 
> things too. Another, issue is the XML syntax that's makes editing without 
> tool support very hard.
>
>
> Most of the newer build tools like Maven, Gradle and Bazel seem to be more 
> oriented towards either IDEs or large-scale projects. Make scales quite 
> nicely to small, and moderately well to large. Recursive builds tend to be 
> a problem, but fortunately with Go, you don’t tend to need those.
>
> I would say Go tooling goes along rather well with Make if you’re 
> following the semi-canonical repo structure, because you can tell Go to 
> just build a list of executables from the ./cmd directory and the build 
> tool takes care of caching, figuring out dependencies, etc. Not much in the 
> way of portability issues there.
>
> Gradle would be another candidate. I am just began to explore it. It's a 
> bit like Maven with human syntax, but lacks again on lifecycle support that 
> I like with Maven.
>
>
> I feel like Gradle is another very Java-oriented tool, and as a 
> consequence seems to have inherited the very Byzantine nature of nearly 
> every other Java ecosystem tool. I haven’t tried to use it for non-Java 
> stuff, but I wouldn’t, personally. Not least because in a CI environment, I 
> tend to try to stick to things either native to the language I’m using (so, 
> the native Go build tools, *maybe* mage), or things present or easily 
> installed in the host Docker image (both Bourne shell and Make fit this 
> bill nicely).
>
> The other benefit here is that in the projects I work on for work, not 
> everyone wants to use Make (some folks have a pathological aversion to it), 
> but it’s easy for us to make sure that Make is only ever a convenience 
> method for things that can otherwise be easily done from the command-line 
> (e.g. “go test ./…”). Make then becomes a) a convenience for running basic 
> things (e.g. make test, make cover, make docker-test-race, that sort of 
> thing) and b) a method for making sure our developers are running the same 
> commands locally that the CI process does (don’t underestimate the 
> importance of that for avoiding difficult-to-diagnose problems).
>
> It’s also nothing you can’t do with plain shell scripts, but you’ll find 
> yourself reinventing a lot of things that Make does for you quite nicely 
> out of the box, like default parameters, list handling, target 
> dependencies, etc.
>
>
> - Dave
>

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

[go-nuts] An interesting thread on Python Packing with lots of discussion about Go

[Amnon]

https://threadreaderapp.com/thread/1427077655627661315.html

-- 
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/3df8793b-ec0c-4929-9b89-c23bc51b39bcn%40googlegroups.com.

[go-nuts] Re: Why isn't go more popular?

[Amnon]

I think Go is actually quite popular.
Especially with people on this list

On Wednesday, 11 August 2021 at 06:45:06 UTC+1 tapi...@gmail.com wrote:

> Personally, Go will become more popular if we could develop gfx/gui apps 
> in Go with ease.
>
> On Thursday, August 5, 2021 at 10:20:49 PM UTC-4 santino.f...@gmail.com 
> wrote:
>
>> When you see the ranking of the most liked programming languages, go is 
>> near c++, a really "hated app". But since is efficient and produces really 
>> clean code, why no wants like it ?
>
>

-- 
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/c0d38ee0-8427-4582-ab4b-dc7645585d1cn%40googlegroups.com.

[go-nuts] Re: Research on Go memory model and race detector

[Amnon]

Good luck with your thesis.

It is worth looking at Russ Cox's blog, where he is giving Memory models 
his usual thorough treatment.

https://research.swtch.com/mm.

I suspect that memory models may be getting increased attention because of 
the increased usage of Arm processors,
with more relaxed memory models.

The third article, about the Go memory model is due next week.

On Friday, 11 June 2021 at 18:18:00 UTC+1 Daniel Fava wrote:

> golan...@googlegroups.com
>
> Hi,
>
> I will defending my PhD thesis, which is about the Go memory model and 
> about race detection in the setting of channel communication. 
>
> Feel free to look at the abstract to see if this might be something that 
> interests you.  You can find a draft of the thesis here:
>
> https://dfava.github.io/thesis/dfava_draft.pdf
>
> The defense is on Monday (June 14), here is how to join the presentation:
>
>
> https://www.mn.uio.no/ifi/forskning/aktuelt/arrangementer/disputaser/2021/fava.html
>
> Besides the introduction (chapter 1), chapter 4 might be the most 
> interesting to the community.  It talks about changes we've made to 
> runtime/chan.go and to the thread sanitizer so that the Go race detector 
> better matches the Go memory model.  These changes were part of Go's 1.16 
> release.
>
> Cheers,
>
> Daniel S. Fava
> [image: Sent from Mailspring]

-- 
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/033780a8-e40b-4ef5-b8a4-1311ec5cd0ecn%40googlegroups.com.

Re: [go-nuts] Re: Contributing to golang based project on github - collaboration best practice

[Amnon]

This needs to be updated for post-GOPATH modules.

On Monday, 14 June 2021 at 20:35:22 UTC+1 Sachin maurya wrote:

> I think this post might help
>
>
> https://penthaa.medium.com/contributing-to-open-source-go-projects-on-github-a-recipe-to-clone-forked-go-repos-4b52a1b36489
>
> On Wednesday, February 3, 2021 at 1:24:12 PM UTC-5 yue.ni...@gmail.com 
> wrote:
>
>> Thank you for the different approaches.
>>
>> I have settled on the go.mod approach as proposed by Shulhan.
>>
>> Cheers
>> On Wednesday, 3 February 2021 at 02:31:04 UTC-8 Adrian Ho wrote:
>>
>>> On 3/2/21 2:21 pm, Volker Dobler wrote: 
>>> > To create a Github PR: git push to your fork (add it as an additional 
>>> > git remote) and create the PR. The "fork" is just a vehicle for a 
>>> > Github PR and nothing you do work on (or try to build). 
>>> > 
>>> For a concrete example of what Volker's talking about, see the `git` 
>>> commands and general workflow in Homebrew's docs on creating pull 
>>> requests: https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request 
>>>
>>> -- 
>>> Best Regards, 
>>> Adrian 
>>>
>>>

-- 
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/8a274f26-2a48-41a7-b84b-94382f5488f4n%40googlegroups.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[Amnon]

I find that people coming to Go from C++ tend to use pointers everywhere so 
as to avoid copying of structs.
Once they get a bit more experience, they tend to use fewer pointers, and 
are happier to pass structs around.
Removing the "make everything a pointer" optimisation makes the code 
simpler, and often actually makes it run faster
as fewer values escape the heap. Allocation tends to dominate Go runtime, 
so it is worth doing a bit more
copying in order to get a bit less allocations. 

On Saturday, 5 June 2021 at 22:34:09 UTC+1 axel.wa...@googlemail.com wrote:

> I would add that because the dynamic type of an interface value is not 
> known at compile time, a variable of interface type really can't (in 
> general) have a specific size.
> If a function has an interface parameter, it must be possible to pass a 
> value of *any* size to it. So even aside from what the current 
> implementation does - any Go compiler must, in general¹, consider 
> interfaces to be pretty-much-pointers.
>
> "in general" because a compiler can, of course, determine that in a 
> certain scenario the value doesn't have to be packed and pass it as-is. 
> This is an optimization sometimes called "devirtualization". But in the 
> general case, a compiler can't prove that (e.g. the dynamic value in an 
> interface could be determined by a random number generator), so it will 
> always be an optimization and the default always has to be a form of boxing 
> into a constantly sized shape.
>
> All of this is a good indication, from first principles, that you don't 
> have to worry about the size of the dynamic value when passing it.
>
> What's more, in general you should trust the author of the package you are 
> using to give you a reasonable implementation of an interface. You 
> shouldn't worry what the dynamic type and value in an interface is, unless 
> you have very good reason to care. In this case, unless you notice that 
> your code is very slow if you don't use a pointer (that would be "a very 
> good reason to care"), you shouldn't optimize it. And if you notice, you 
> should open a bug against that package :) Though as established, you won't.
>
> On Sat, Jun 5, 2021 at 11:18 PM Ian Lance Taylor  wrote:
>
>> On Sat, Jun 5, 2021 at 2:15 PM Joshua  wrote:
>> >
>> > My question is general, but for ease of communicating I'll use the 
>> specific example I ran into.
>> >
>> > I'm very new and for my first project I'm working with the bleve 
>> library [https://pkg.go.dev/github.com/blevesearch/bleve].
>> >
>> > One function I need, "Open", returns an interface, "Index".
>> >
>> > I'd like to write my own function to act on this interface, and given 
>> that I have no idea what the dynamic value of the interface is, my first 
>> instinct is to rather pass a pointer to the returned interface into my 
>> function.
>> >
>> > However, I see lots of calls of "If you're using pointers to interfaces 
>> a lot, you probably don't understand them".
>> >
>> > Well, what am I not understanding?
>> > My worry is that I have no idea what dynamic type is lurking within the 
>> interface, if it's a pointer to a struct, then I obviously don't mind 
>> passing it into my function.
>> >
>> > However if it is in fact a humungous 1GB struct, then I really really 
>> don't want to be copying that around willy-nilly.
>> >
>> > Is there a way in general to avoid this, without looking at the library 
>> source code to see what the actual concrete type is?
>>
>> In the current implementations a value of interface type is always a
>> pair of pointers.  Even if the value of interface type happens to
>> refer to a 1GB struct, copying the interface value, including passing
>> it to a function or returning it from a function, always just copies
>> two pointers.
>>
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcUuv_qrrG8%3DdCQZv0%2BrKbnbW60XdOCwjp8M3EdOCxCNkw%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/2fc297cf-0068-4547-8316-e0512169c91fn%40googlegroups.com.

Re: [go-nuts] Re: Ignore /vendor by default in polyglot repository

[Amnon]

How about renaming your vendor directory to something else?

On Friday, 4 June 2021 at 21:44:33 UTC+1 Brian Candler wrote:

> I don't suppose you could move all the go code down a level, say into a 
> "go" subdirectory of the repo, including the go.mod file?
>
> On Friday, 4 June 2021 at 17:44:37 UTC+1 manlio@gmail.com wrote:
>
>> On Friday, June 4, 2021 at 6:24:28 PM UTC+2 Jacob Vosmaer wrote:
>>
>>> On Thu, Jun 3, 2021 at 6:35 PM Manlio Perillo  
>>> wrote: 
>>> > One possible solution is to have a GOENV file in the root directory of 
>>> a repository. 
>>> Thanks Manlio. Is that something that is possible now, or a feature 
>>> suggestion? From what I can tell it's not possible now. 
>>>
>>>
>> It was only a suggestion.
>> I don't know if the Go team is willing to add additional complexity to 
>> the go command.
>>  
>>
>>> What is possible already, now that I think about it, is for us to ask 
>>> our contributors to run 'go env -w GOFLAGS=-mod=mod'. It's not 
>>> something I would recommend in general because by the time you run 
>>> into a problem because of that global value, you typically have 
>>> forgotten you put it there. 
>>>
>>>
>> Have you thought about using a Makefile?  Or a make.bash/test.bash script?
>>
>> I think my ideal solution would be more specific to vendoring; for 
>>> example a sort of pragma in vendor/modules.txt that tells the 
>>> toolchain to act as if there is no vendoring after all. But I don't 
>>> know the topic well enough to understand the implications of that. 
>>>
>>>
>> One possible solution that is possible now is to set the go version in 
>> the go.mod file to 1.13, so that the vendor directory is ignored:
>>
>> https://github.com/golang/go/blob/2e59cc5fb4/src/cmd/go/internal/modload/init.go#L699
>>
>> However it will prevent the use of recent features, like the embed 
>> package.
>>  
>> Manlio 
>>
>

-- 
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/323f139e-551d-4f62-b513-00cfa0ccc995n%40googlegroups.com.

[go-nuts] Re: json unmarshalling troubles

[Amnon]

No, whoever designed the schema of this API has lost their marbles,
(or lacks any kind of consideration for the unfortunate souls who need to 
use this API).

Unmarshalling a value whose type is not fixed is a pain in Go.
But handling a value of unknown type will be a headache in any language.



On Wednesday, 2 June 2021 at 19:55:40 UTC+1 rob...@glonek.co.uk wrote:

> I think I'm loosing my marbles. Nevermind what I said.
>
> On Wednesday, 2 June 2021 at 16:22:34 UTC+1 Brian Candler wrote:
>
>> > If you try using switch value.(type) instead of using reflect, bool 
>> will be reported as int, fyi, so using reflect here.
>>
>> Could you explain that a bit further please?  A type switch seems to work 
>> OK for me, with no reflect.
>> https://play.golang.org/p/TBH5zKYnG4G
>>
>>

-- 
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/3b039ea4-7c16-4472-9bfc-4a626bf82478n%40googlegroups.com.

[go-nuts] Re: Equivalent Interfaces - why does this fail to compile?

[Amnon]

yes, but surely the return types are equivalent?

On Monday, 24 May 2021 at 17:08:07 UTC+1 asv...@gmail.com wrote:

>
> Interfaces are not equal: "m2() aer" and "m2() ber" has different return 
> type. Even compiler told you about it.
> On Monday, May 24, 2021 at 9:20:51 AM UTC+3 Amnon wrote:
>
>> See https://play.golang.org/p/5x9JrD55WKc
>>
>> The interfaces aer and ber look equivalent.
>> Both contain a function which returns nothing called m1
>> and a function which returns another an instance of the interface m2.
>>
>> If we comment out m2, then the code will compile.
>> But otherwise we get an error:
>>
>> ./prog.go:14:5: cannot use a (type aer) as type ber in argument to bar: 
>> aer does not implement ber (wrong type for m2 method) have m2() aer want 
>> m2() ber 
>>
>> even though aer and ber should be equivalent!
>>
>> package main
>>
>> type aer interface {
>> m1()
>> m2() aer
>> }
>>
>> type ber interface {
>> m1()
>> m2() ber
>> }
>>
>> func Foo(a aer) {
>> bar(a)
>> }
>>
>> func bar(b ber) {
>> }
>>
>> func main() {
>> }
>>
>>

-- 
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/dcac0e8a-9dbd-4ac1-9670-b78243c9d2d1n%40googlegroups.com.

[go-nuts] Equivalent Interfaces - why does this fail to compile?

[Amnon]

See https://play.golang.org/p/5x9JrD55WKc

The interfaces aer and ber look equivalent.
Both contain a function which returns nothing called m1
and a function which returns another an instance of the interface m2.

If we comment out m2, then the code will compile.
But otherwise we get an error:

./prog.go:14:5: cannot use a (type aer) as type ber in argument to bar: aer 
does not implement ber (wrong type for m2 method) have m2() aer want m2() 
ber 

even though aer and ber should be equivalent!

package main

type aer interface {
m1()
m2() aer
}

type ber interface {
m1()
m2() ber
}

func Foo(a aer) {
bar(a)
}

func bar(b ber) {
}

func main() {
}

-- 
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/4112dd4a-f2b3-4469-806e-233f242f93f9n%40googlegroups.com.

Re: [go-nuts] How to cast a multi-value?

[Amnon]

My understanding was that a string had a pointer and a length,
whereas a slice had a pointer and a length and a capacity.

https://golang.org/src/reflect/value.go?s=59515:59567#L1973


On Tuesday, 18 May 2021 at 20:32:39 UTC+1 Brian Candler wrote:

> Assigning a string value to another variable doesn't double the memory 
> usage.
>
> A value of type string consists of a pointer, a length, and a capacity, 
> and only these are copied - so you get another copy of the pointer, 
> pointing to the same data buffer.
>
>>

-- 
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/951b1505-e6d7-42d0-b78e-cea207956281n%40googlegroups.com.

[go-nuts] Re: Map to struct and vice versa

[Amnon]

https://programmersought.com/article/93641771999/

On Monday, 17 May 2021 at 10:26:14 UTC+1 nick@gmail.com wrote:

> Is there an easy way to go from a map to a struct and vice versa? e.g. 
> going from:
> m := map[string]interface{}{"a": "x", "b": 5}
>
> to an instance of:
>   type T struct {
> A string
> B int
>   }
>
> I can do this going through JSON (marshal the map, unmarshal into struct),
> but is there a more direct way?
>

-- 
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/ac267813-f553-4d65-b4eb-4642c640237an%40googlegroups.com.

[go-nuts] Re: Reflect on Rust for Android and Linux kernel support

[Amnon]

I would agree with all Uli's points. 
I would add that not that many kernel developers - around 15,000
and most of these just write device drivers.
So kernel development is very much a niche occupation.
C as a very low level language - basically a pretty assembler, with no 
runtime, is ideally suited to Kernel development.
Adapting the Kernel to allow development in a higher level language with GC 
is not trivial. For one thing, 
Kernel code needs to deal with different kinds of memory allocations, 
different kinds of memory and different address spaces.

I have not been following the discussions on the Kernel mailing lists for 
many years, so I am not sure what problem enabling Rust 
to be used inside the Kernel will solve. But if Kernel developers want to 
do the work to enable
Rust to be used for Kernel development, then all power to them.

Go was never meant to be all things to all people, and in an ideal world 
people will use the tool most suited to the job.
Go benefits from having a very clear vision, and being designed to solve a 
specific problem (server/cloud programming).
And Go's growth over the years suggests that it does this well.
Diluting this vision in order to cover more niche areas might not improve 
the language.

- amnon
On Sunday, 9 May 2021 at 08:40:52 UTC+1 Uli Kunitz wrote:

> There are multiple differences that make Rust a better replacement for 
> C/C++ code than Go:
>
> * Go requires a garbage collector and its own scheduler (A Go without GC 
> and goroutines is not Go.)
> * Go has its own ABI and CGO calls are slow
> * Rust makes guarantees about memory safety that Go doesn't do. 
>
> While there are already experimental Linux kernel modules in Rust, I have 
> only read about researchers who wrote a whole kernel in Go. But a new 
> kernel requires an ecosystem and it is hard to see, how the industry as a 
> whole will support this. So you would need to write Linux kernel modules in 
> Go and it would need to have advantages over kernel modules in Rust. It is 
> hard to see how this will come about.
>
> There is now a group of developers working to integrate Rust with the 
> kernel. But they also have challenges like panics in the Rust core 
> libraries and the plan to interact with the Linux kernel through a safe 
> API. I guess it will take still a year or two before Rust code has been 
> merged into the Linux mainline kernel. At this point, it is not obvious 
> whether the majority of new code will be written in Rust or C for the Linux 
> kernel 10 years from now. 
>
> I don't know anything about the reasons and drivers for the Rust 
> Foundation, but having observed the open-source landscape for the last 30 
> years I can say the following. Foundations usually address two main issues: 
> funding of the core development team and addressing intellectual property 
> rights issues.  Go is very well funded by Google, so this is not a driver. 
> Google has pooled patents with IBM and others for open source in the Open 
> Invention Network and is able to fund litigation up to the Supreme Court of 
> the United States. So legal issues are also no reason for a foundation. 
> There could be a third objective for a foundation, which would be community 
> governance of the Go development, but the proposal process works well and I 
> cannot see, how a foundation would improve it.  This doesn't say a 
> foundation may be required in the future, but right now the usual drivers 
> don't apply.
>
> Greetings,
>
> UIi
>
> On Saturday, May 8, 2021 at 11:28:54 PM UTC+2 xiao...@gmail.com wrote:
>
>> Hi, I may not well thought about this, hope someone else here can take 
>> this seriously and have some change( say invest more on some area: kernel, 
>> android, the area that Rust can do, etc ) or something else change maybe.
>>
>> You can take this as a feedback.
>>
>> I've see Rust in the Android platform 
>> <https://security.googleblog.com/2021/04/rust-in-android-platform.html>  
>> and Rust in the Linux kernel 
>> <https://security.googleblog.com/2021/04/rust-in-linux-kernel.html>, and 
>> Rust even got Rust foundation that Google, Amazon, Microsoft joined, with 
>> recently Facebook Joins the Rust Foundation 
>> <https://developers.facebook.com/blog/post/2021/04/29/facebook-joins-rust-foundation/>
>>  joined.
>>
>> Here I've got some question, forgive me if I'm just stupid to understand 
>> the situation
>>
>> 1. What things that Rust can do, and Go can't ( even do better ), to get 
>> them select Go as better choice.
>> 2. Should we have a foundation rather than  pure opensource. so to get 
>> better support from all big company( officially ). I see CNCF 
>> <http://cncf.io/> foundation is a good example

[go-nuts] Re: How to merge two Unstructured objects type ?

[Amnon]

Aha.
OK, 
is 
https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured#Unstructured.DeepCopyInto
what you are looking for?

On Sunday, 2 May 2021 at 19:18:43 UTC+1 mmahmo...@gmail.com wrote:

>
> https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured#section-documentation
>
> I am looking for something like the following 
> func mergeObjects(obj1 *uns.Unstructured, obj2 *uns.Unstructured) 
> (*uns.Unstructred, error) {
>
> }
>
> Thanks
> On Sunday, May 2, 2021 at 1:35:06 PM UTC-4 Amnon wrote:
>
>> I am not sure what you mean by an unstructured object.
>> So probably best if you show us the code where they are defined.
>>
>> On Sunday, 2 May 2021 at 16:37:12 UTC+1 mmahmo...@gmail.com wrote:
>>
>>> Hi All:
>>>
>>>  I am using two unstructured objects to represent two different 
>>> ConfigMaps, of the same everything but different data,  I am looking for a 
>>> way/API to merge both into one ConfigMap
>>>
>>> I am looking for something like DeepAppend() or DeepMerge() 
>>> any suggestion or recommendation ?
>>>
>>> Thanks,
>>> Mohamed
>>>
>>

-- 
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/9fe1da2f-cf8a-493c-b040-1876a78c0196n%40googlegroups.com.

[go-nuts] Re: How to merge two Unstructured objects type ?

[Amnon]

I am not sure what you mean by an unstructured object.
So probably best if you show us the code where they are defined.

On Sunday, 2 May 2021 at 16:37:12 UTC+1 mmahmo...@gmail.com wrote:

> Hi All:
>
>  I am using two unstructured objects to represent two different 
> ConfigMaps, of the same everything but different data,  I am looking for a 
> way/API to merge both into one ConfigMap
>
> I am looking for something like DeepAppend() or DeepMerge() 
> any suggestion or recommendation ?
>
> Thanks,
> Mohamed
>

-- 
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/60546b1e-0f0a-45c9-ac06-e1ed9440ced6n%40googlegroups.com.