[go-nuts] Re: Is it possible to get code coverage information in a way that does not assume you can see color?

['drc...@google.com' via golang-nuts]

I reopened an old bug for this, and perhaps it will get some attention.
https://github.com/golang/go/issues/6623

On Sunday, January 12, 2020 at 1:19:59 AM UTC-5 Fazlul Shahriar wrote:

> I also wrote a tool like that: https://github.com/fhs/golinecov
> It displays coverage report from 'go test' without any color or fancy HTML.
> I wrote it because I wanted something text oriented that I can view within 
> my editor.
> Hope it's useful.
>
> fhs
>
>
> On Saturday, January 11, 2020 at 1:41:01 AM UTC-5, andrew...@elastic.co 
> wrote:
>>
>> On Thursday, January 9, 2020 at 11:39:41 PM UTC+8, Jared Stofflett wrote:
>>>
>>> I'm a totally blind developer who is trying to learn go. When running
>>>
>>> go tool cover -html=cover.out -o cover.html
>>>
>>> It appears the HTML generated uses color to show the lines of code that 
>>> are not covered without any other way of identifying uncovered lines. This 
>>> is obviously an issue if your totally blind. Are there any alternative 
>>> tools that can take a coverage profile and give a text representation of 
>>> lines that are not covered?
>>>
>>
>> A long time ago I wrote a tool that will annotate source code with 
>> coverage, generating plain text output. Lines that are not covered will be 
>> annotated with "MISS". I don't know how well this will work for you, but 
>> you could give it a try. You can find it here: 
>> https://github.com/axw/gocov
>>
>> You can annotate the source of the package in your current working 
>> directory by running "gocov test | gocov annotate -". The hyphen at the end 
>> is necessary to read from stdin.
>>
>> Hope this helps.
>>
>> Cheers,
>> Andrew
>>
>

-- 
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/5552940d-eb27-49f4-a017-b35a54f3a489%40googlegroups.com.

[go-nuts] Re: Is it possible to get code coverage information in a way that does not assume you can see color?

['drc...@google.com' via golang-nuts]

Different, new bug instead: https://github.com/golang/go/issues/36685

On Tuesday, January 21, 2020 at 4:33:00 PM UTC-5 drc...@google.com wrote:

> I reopened an old bug for this, and perhaps it will get some attention.
> https://github.com/golang/go/issues/6623
>
> On Sunday, January 12, 2020 at 1:19:59 AM UTC-5 Fazlul Shahriar wrote:
>
>> I also wrote a tool like that: https://github.com/fhs/golinecov
>> It displays coverage report from 'go test' without any color or fancy 
>> HTML.
>> I wrote it because I wanted something text oriented that I can view 
>> within my editor.
>> Hope it's useful.
>>
>> fhs
>>
>>
>> On Saturday, January 11, 2020 at 1:41:01 AM UTC-5, andrew...@elastic.co 
>> wrote:
>>>
>>> On Thursday, January 9, 2020 at 11:39:41 PM UTC+8, Jared Stofflett wrote:

 I'm a totally blind developer who is trying to learn go. When running

 go tool cover -html=cover.out -o cover.html

 It appears the HTML generated uses color to show the lines of code that 
 are not covered without any other way of identifying uncovered lines. This 
 is obviously an issue if your totally blind. Are there any alternative 
 tools that can take a coverage profile and give a text representation of 
 lines that are not covered?

>>>
>>> A long time ago I wrote a tool that will annotate source code with 
>>> coverage, generating plain text output. Lines that are not covered will be 
>>> annotated with "MISS". I don't know how well this will work for you, but 
>>> you could give it a try. You can find it here: 
>>> https://github.com/axw/gocov
>>>
>>> You can annotate the source of the package in your current working 
>>> directory by running "gocov test | gocov annotate -". The hyphen at the end 
>>> is necessary to read from stdin.
>>>
>>> Hope this helps.
>>>
>>> Cheers,
>>> Andrew
>>>
>>

-- 
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/fb8e8a38-5d27-49f1-b90b-3b3ca54096ac%40googlegroups.com.

Re: [go-nuts] Bound checks elimination hint.

['drc...@google.com' via golang-nuts]

FYI, strided iteration is something we're trying to do better but this is 
very tricky code, and it is also possible for it to get very expensive at 
compile time.  
On Saturday, February 22, 2020 at 4:42:03 PM UTC-5 Nigel Tao wrote:

> On 2/23/20, Bruno Albuquerque  wrote:
> > Would adding an explicit len() check before the loop help the
> > compiler in any way (can not test right now)?
>
> I don't know. Sorry.
>

-- 
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/5659e74b-b823-41de-84ad-c14cbd8e45a9%40googlegroups.com.

Re: [go-nuts] Why not use F in generic？

['drc...@google.com' via golang-nuts]

We could regard the function as a method on the type(s), maybe?
Not sure if this is a good idea or not, especially since we don't have 
multimethods (methods applied to multiple values) for ordinary values.

On Monday, June 22, 2020 at 1:53:56 PM UTC-4 Ian Lance Taylor wrote:

> On Mon, Jun 22, 2020 at 10:09 AM James L  wrote:
> >
> > Have you read other thread which have been answered many times?
>
> In fairness, this idea is different, because the type comes first.
> Since the '<' character will always be the start of an expression, I
> think it may be unambiguous. I think this has been suggested before
> also, though I'm not sure where.
>
> I don't personally like this syntax because it seems to put the cart
> before the horse. In a function call, I would expect to see the Print
> function with a type argument int. This flips the order so that we
> see int first, then we see that we are talking about the Print
> function. Even if it could work syntactically, it seems to me to be
> less readable.
>
> The goal in any syntax suggestion should be more than just "this might
> work." It should be "this is more readable and easier to understand."
> And personally I don't think this specific suggestion meets that
> goal.
>
> Thanks for the comment, though.
>
> Ian
>
>
> > On Tue, 23 Jun 2020 at 12:46 AM,  wrote:
> >>
> >> I read the new generic draft. And I know F,F[T],F《T》 is discarded. I 
> think put the type paremeter in front of the function name may be better. 
> No ambiguous and more readable code.
> >>
> >> func Print(type T)(s []T) {
> >>
> >> }
> >>
> >> Print(int)([]int{1, 2, 3})
> >>
> >> func Print(s []T) {
> >>
> >> }
> >>
> >> Print([]int{1, 2, 3})
> >>
> >>
> >>
> >> --
> >> 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/c55ab443-4333-4def-9d9c-6657463a4a75o%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/CAHo5hB6-myagSyixYPfghVYBE3DUpQMYSj88%2BjB74hbJvzQApQ%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/8df1b05b-3e0c-4b3d-a714-a6cf34964f45n%40googlegroups.com.

Re: [go-nuts] insane idea to eliminate CGO latency

['drc...@google.com' via golang-nuts]

Go "cares" because in Go it's common for a single OS thread to correspond 
to 25-100% of runnable goroutines.

So the accounting for "how many OS threads are available to run goroutines" 
tends to be fine-grained,
otherwise weird failure-to-schedule bugs can occur. It's likely it could be 
improved, but it's not at all easy,
especially if we factor in the problem of testing it, and any weird 
performance effects on other Go programs.



On Sunday, March 14, 2021 at 10:54:43 PM UTC-4 ren...@ix.netcom.com wrote:

> True. I was collapsing the two because why does Go care. If the routine is 
> in a C native call don’t switch the routine assigned to the thread. 
> Similarly. If the thread is in C native it can’t affect stacks / heap 
> structures - so routines that make C calls only need to ensure a C minimum 
> stack size. The state I was referring to supports the determination of “is 
> running native” and if so “leave it alone” until it returns to Go code. As 
> long as the pointers passed to the C code are either native (non heap) or 
> tracked the C code is “safe”. 
>
> So to that point, it’s confusing as to why the scheduler is the bottleneck 
> in calling C code. 
>
> > On Mar 14, 2021, at 9:38 PM, Ian Lance Taylor  wrote:
> > 
> > On Sun, Mar 14, 2021 at 1:46 PM Robert Engels  
> wrote:
> >> 
> >> That was my point, based on Java, there is the ability to make the GC 
> coordination extremely efficient a read and two writes per Go to C complete 
> call trip - and this can often be eliminated in tight loops.
> > 
> > I don't mean to drag out the conversation but I'm not sure I
> > understand the point. I think you were the first person to mention GC
> > coordination. I don't think there is any GC coordination issue here.
> > There is a scheduler coordination issue, specifically the need to
> > inform Go's goroutine scheduler that the goroutine is changing
> > behavior.
> > 
> > Ian
> > 
> > 
> >> So if the scheduling is the source of inefficiency there are more 
> simple ways to tackle than this proposal.
> >> 
>  On Mar 14, 2021, at 3:04 PM, Ian Lance Taylor  
> wrote:
> >>> 
> >>> On Sun, Mar 14, 2021 at 12:00 PM Robert Engels  
> wrote:
>  
>  Based on two decades of Java FFI - the overhead comes from type 
> mapping not the housekeeping to control GC. The latter can be as simple as 
> a volatile read and 2 writes per call and can usually be coalesced in tight 
> loops. Since Go already has easy native C type mapping the FFi should be 
> very efficient depending on types used.
> >>> 
> >>> Go and Java are pretty different here. The type mapping overhead from
> >>> Go to C is effectively non-existent--or, to put it another way, it's
> >>> pushed entirely onto the programmer The GC housekeeping is, as you
> >>> say, low. The heaviest cost is the scheduling housekeeping: notifying
> >>> the scheduler that the goroutine is entering a new scheduling regime,
> >>> so that a blocking call in C does not block the entire program. A
> >>> minor cost is the change is the calling convention.
> >>> 
> >>> As Jason says, if all of the C code--and I really do mean all--can be
> >>> compiled by a Go-aware C compiler, then the scheduling overhead can be
> >>> largely eliminated, and pushed into the system call interface much as
> >>> is done for Go code. But that is a heavy lift. Compiling only some
> >>> of the C code with a Go-aware C compiler seems unlikely to provide any
> >>> significant benefit.
> >>> 
> >>> Ian
> >>> 
> >>> 
> >>> 
>  On Mar 14, 2021, at 11:37 AM, Jason E. Aten  
> wrote:
>  
>  > I'm no authority here, but I believe a large (major?) part of the 
> Cgo overhead is caused by scheduling overhead. As I understand it, a C 
> function call is non-preemptible and the Go runtime don't know whether the 
> call will block.
>  
>  But that part would be handled by the C-compiler-that-knows-Go 
> inserting the pre-emption points just like the Go compiler does into the 
> generated code. Or the same checks for blocking.
>  
>  --
>  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/0ac6ac9e-ed99-4536-a8b0-44674f8b85a5n%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/47869391-FC69-44C8-A7AA-8F335A17CF71%40ix.netcom.com
> .
> >>> 
> >>> --
> >>> You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> >>> To unsubscribe from this group and 

[go-nuts] Re: meaning of SSA operation

['drc...@google.com' via golang-nuts]

Also, be aware that work that we really hope lands in 1.17 will tinker with 
all the call operations.

The goal is to switch to an ABI that passes parameters to/from calls in 
registers, and the way
that ends up expressed in SSA is that first (and we do this part in 1.16) 
the parameters to the 
call will appear as inputs, and the results will be obtained with 
OpSelectN.  The call will still
receive and return a memory value, as last input and last element of result.

This is then lowered to a machine-agnostic level where some parameters are 
stored in memory,
the others in registers -- where the registers appear as inputs/outputs of 
the call -- and then
further lowered (simple OpCode rewrite) to machine-specific call 
instructions.  The registers themselves
are bound in the register allocator, by the "trick" of telling it that 
Calls have only a single appropriate
register for each of their inputs/outputs.

This might look a little odd the first time you see it.

And, also, the order in which the registers inputs/outputs are encoded is 
not fixed; for compiler
efficiency purposes, we *might* reorder them so that all the integer 
registers come first, etc.
(This would allow a lot more sharing of register masks.)

This full change is likely only for amd64 in 1.17, then for other 
architectures once we figure out
the exact recipe.  It touches many parts of the compiler and runtime.

On Wednesday, March 24, 2021 at 4:01:36 AM UTC-4 Ge wrote:

> Thank you Keith for clarification. It's really of great help.
>
> Ge
>
> 在2021年3月24日星期三 UTC+8 上午7:45:13 写道：
>
>> On Tuesday, March 23, 2021 at 9:11:13 AM UTC-7 Ge wrote:
>>
>>>
>>> Hi,
>>> Recently I encountered a problem which seems to be related to SSA 
>>> optimization 
>>> and feels hard to figure out what some SSA operation means.
>>>
>>> Code:
>>> case1:
>>> func main() {
>>> var x int
>>> go func() {
>>> for {   
>>> x++  //no matter "-N" compile flags is specified or 
>>> not, 'x++' will be optimized
>>> }
>>> }()
>>> println(x)
>>> }
>>>
>>> case2:
>>> func main() {
>>> var x int
>>> go func() {
>>> for {   
>>> x++  
>>> dummy()   // when empty function 'dummy' is added to this 
>>> infinite loop, ''x++' stays last
>>> }
>>> }()
>>> println(x)
>>> }
>>>
>>> //go:noinline
>>> func dummy() {
>>> }
>>>
>>> I tried 'GOSSAFUNC=main.func1 go tool compile case2.go' and found the 
>>> key point is
>>> deadcode phase in SSA. Here is CFG before 'early deadcode' phase:
>>>
>>> ``` *ssaoptx.go*
>>> 5  go func() {
>>> 6  for {
>>> 7  x++
>>> 8  dummy()
>>> 9  }
>>> 10 }()
>>> ```
>>>
>>> ``` *early copyelim*
>>>
>>>- b1:
>>>- 
>>>   - v1 (?) = InitMem 
>>>   - v2 (?) = SP 
>>>   - v3 (?) = SB 
>>>   - v4 (?) = LocalAddr <**int> {&x} v2 v1
>>>   - v5 (5) = Arg <*int> {&x} (&x[*int])
>>>   - v9 (?) = Const64  [1]
>>>- Plain → b2 (*+6*)
>>>
>>>
>>>- b2: ← b1 b4
>>>- 
>>>   - v14 (7) = Phi  v1 v12
>>>   - v15 (7) = Copy <*int> v5 (&x[*int])
>>>- Plain → b3 (7)
>>>
>>>
>>>- b3: ← b2
>>>- 
>>>   - v6 (7) = Copy <*int> v5 (&x[*int])
>>>   - v7 (7) = Copy  v14
>>>   - v8 (*+7*) = Load  v5 v14
>>>   - v10 (7) = Add64  v8 v9
>>>   - v11 (7) = Store  {int} v5 v10 v14
>>>   - v12 (*+8*) = StaticCall  {"".dummy} v11
>>>- Plain → b4 (8)
>>>
>>>
>>>- b4: ← b3
>>>- Plain → b2 (7)
>>>
>>>
>>>- b5:
>>>- 
>>>   - v13 (10) = Unknown 
>>>- Ret v13
>>>
>>> ```
>>> deadcode phase will traverse all blocks and find out the reachable 
>>> blocks 
>>> (In above example is b1,b2,b3,b4, while b5 is isolated block), Second it 
>>> will
>>> find out live values based on reachable blocks and eliminate dead values.
>>>
>>> The call of dummy function makes v8,v10,v11 all live so 'x++' isn't 
>>> optimized.
>>> I have read ssa/README.md but still had some questions.
>>>
>>> 1. The role of InitMem.
>>>  It seems that every function starts with it, are some initialize 
>>> work like 
>>>  stack space allocation and named return values initialization done 
>>> by it?
>>>
>>>
>> Not really. Stack space and any zeroing required are done when generating 
>> the preamble. They are not represented in SSA.
>> InitMem is just the initial state of memory on entry to the function. It 
>> does not generate any actual code.
>>  
>>
>>> 2.  The meaning of 'v14 (7) = Phi  v1 v12'.
>>>   It looks like v14 = Φ(v1, v12), but I don't know why InitMem and 
>>> dummy function
>>>   call will affect here.
>>>
>>> 3.  The meaning of of  StaticCall's argument .
>>>   Some ssa operations are easy to understand,  for example,  
>>>   'v8 (*+7*) = Load  v5 v14' means v8=Load(v5) and v14 is 
>>> the memory statewhich implies this load operation must happens 
>>> after v14 is determined.
>>>
>>>   That's all I know from README.md, but about ot

[go-nuts] Re: Table-driven benchmarks defeat inlining

['drc...@google.com' via golang-nuts]

On Sunday, June 6, 2021 at 8:35:02 AM UTC-4 Paul S. R. Chisholm wrote:

> For example, could this code:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = 0
> for i := 0; i < b.N; i++ {
> sum += PopCount(0x1234567890abcdef)
> }
> }
>
> hypothetically be optimized to:
>
> func BenchmarkPopCountAlive(b *testing.B) {
> sum = PopCount(0x1234567890abcdef) * b.N
> }
>
> since PopCount() always returns the same value for the same argument? It 
> probably wouldn't, since that would break many existing benchmarks.
>

We're talking about adding that very optimization, and I estimate the 
chance of it appearing in the next 2 years is above 50%.
Preserving benchmark performance is an anti-goal for people working on 
general-purpose (*) compilers and runtimes.
(*) crypto and real-time are special-purpose.

As to "why", I know of at least three reasons:
- hoisting invariant expressions out of loops is one of those mechanical 
things that computers do pretty well, and Go's package layering makes it 
easy to gather "pure function" information.
- we're getting more and more Go programmers, doing more and more diverse 
things, they won't all be interested in learning hand-optimization tricks.
- when we turn on generics, and as more things are written generically, 
generic-expansion will remove opportunities to hand-optimize code in the 
usual way

So we are *definitely* thinking about this.

As to what to do for your benchmarks, I am not sure.  One obvious answer is 
"write them more carefully", but this does somewhat subvert the idea that 
it's easy to write benchmarks in Go.  We might also provide more guidance, 
as in "a benchmark must do useful work that is consumed or checked" and 
then provide examples of the same.  It's not just the Go compiler, either 
-- if a loop-invariant input causes code to take exactly the same paths 
over and over again, hardware branch predictors will do a better-than-usual 
job.
 

-- 
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/35975862-cfee-4fe5-ad99-70eb83154c1en%40googlegroups.com.

Re: [go-nuts] Warning for look alike Unicode characters

['drc...@google.com' via golang-nuts]

I was going to ask, "how do they define/measure that?", decided to look at 
the Rust code, and 
found http://www.unicode.org/Public/security/10.0.0/confusables.txt
So there's a defined source and everything.

On Friday, June 11, 2021 at 5:48:05 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Jun 11, 2021 at 2:32 PM Delta  wrote:
> >
> > Jun 12, 2021 3:00:01 AM Ian Lance Taylor :
> >
> > > Which context do you mean? You said "the Go tool." Do you mean
> > > something in the tool, or do you mean something in the language?
> > >
> > > For the tool, when does this come up?
> >
> > I don't know why I wrote this. I saw somewhere a post on rustc giving
> > help message in case error was produced due to use of look alike Unicode
> > characters like Greek question mark in place of ;
> >
> > I thought that is cool.
> >
> > I am sorry.
>
> No need to apologize. It's an interesting idea. There is nothing
> similar in Go today.
>
> 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/115d0585-b066-41c5-8d01-e3c638347c98n%40googlegroups.com.

Re: [go-nuts] use delve to debug golang with 'next' will skip some step

['drc...@google.com' via golang-nuts]

That debugging is (now) in the runtime package, which is (always) compiled 
with optimizations on.
That will tend to interfere with debugging.  The 1.17 change to use 
registers for passing parameters
has also caused some regressions in debugging quality (and it would be nice 
to fix those, but it is tricky).

On Tuesday, July 27, 2021 at 6:26:19 PM UTC-4 jake...@gmail.com wrote:

> Was the code built with optimizations disabled?
>
> On Tuesday, July 27, 2021 at 1:57:17 PM UTC-4 林 子鹏 wrote:
>
>> When I use delve to debug this project(dlv debug t.go): 
>>
>> //t.gopackage main
>> import (
>> "fmt"
>> "os"
>> "reflect"
>> "unsafe"
>> )
>> func main() {
>> s1 := make([]uint8, 0)
>> aboutSlice(&s1, "s1")
>> s2 := make([]uint8, 8)
>> aboutSlice(&s2, "s2")
>> new_s1 := append(s1, 10)
>> new_s2 := append(s2, 20)
>> aboutSlice(&new_s1, "new_s1")
>> aboutSlice(&new_s2, "new_s2")
>> os.Exit(0)
>> }
>> func aboutSlice(s *[]uint8, n string) {
>> fmt.Printf("%s:\tmem_addr:%p\tsize:%v\taddr:%#x\tlen:%v\tcap:%v\n", n, 
>> s, unsafe.Sizeof(*s), (*reflect.SliceHeader)(unsafe.Pointer(s)).Data, 
>> len(*s), cap(*s))
>> }
>>
>> I want to analyze the behavior of function growslice(in 
>> runtime/slice.go),and then set breakpoints on func growslice,I use n and 
>> s to analyze it, but it will skip some step, like the picture below:
>>
>

-- 
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/51baac64-0197-4a02-91d6-097bcfb892c5n%40googlegroups.com.

Re: [go-nuts] Does GC pause affect non-go threads spawned by CGo?

['drc...@google.com' via golang-nuts]

The pause also tends to not be large.  Except for bugs (which do exist and 
some of them are hard to fix) the goal on a modern fast processor is under 
100 microseconds of a thread "pausing".  There is a period of time where 
goroutines will make reduced progress as the garbage collector steals 
either time slices or a processor(s), but the intent is that this be as 
concurrent (and parallel) as possible.  It's complex -- in some bugs the 
over-long pause is caused by "bad accounting" where a goroutine simply 
fails to get credit for the work it does on behalf of garbage collection.

On Monday, October 25, 2021 at 1:12:22 PM UTC-4 ren...@ix.netcom.com wrote:

> No, unless they call back into Go. 
>
> On Oct 25, 2021, at 10:43 AM, Amir DER  wrote:
>
> Does GC pause affect non-go threads spawned by CGo?
>
> -- 
> 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/7d165522-f261-4391-9708-eb3ace3fb7a2n%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/a60635a2-fd3e-4921-8640-55600b05b988n%40googlegroups.com.

Re: [go-nuts] Is there any way to force Go to call asm function using register-based arguments?

['drc...@google.com' via golang-nuts]

You could use build tags to write a portable implementation and a (very) 
version-specific implementation.
E.g.
//go:build go1.18 && !go1.19
// go1.18-specific
and
//go:build (go1.8 && !go1.18) || go1.19
// not go1.18

We have ideas about changing the ABI in the future -- possible changes 
include
- use the closure context pointer to pass the receiver to methods
- don't reserve stack space for spilling in the prologue
- perhaps reserve some registers for generational GC, if we ever do that

On Monday, March 7, 2022 at 3:56:43 PM UTC-5 Ian Lance Taylor wrote:

> On Mon, Mar 7, 2022 at 12:37 PM Richiise Nugraha  
> wrote:
>
>> Hi i wonder if there's option to use register-based arguments, maybe like 
>> compiler directive or something?
>>
>> Expected result:
>> But this one wasting r9 as function address.
>> [image: unknown.png]
>>
>>
>> What i got so far:
>> But this is stack-based :/
>> [image: unknown.png]
>>
>
>
> Please always show text as plain text, not as images.  Plain text is much 
> easier to read.  I'm not even going to try to read your images; sorry.
>
> That said, there is no supported way to do this.  You can indicate that an 
> assembly function uses the internal ABI, which is currently the register 
> ABI, by changing "(SB)" to "" in the TEXT directive introducing 
> the function.  However, as you can guess from the name, the internal ABI is 
> subject to change over time.  See 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/27539-internal-abi.md.
>   
> So while it is possible to write such an assembly function today, it may 
> break in future releases.
>
> 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/841077ea-cb74-4e0c-b17d-4cc8e61ffa0en%40googlegroups.com.

Re: [go-nuts] Golang 1.19+ preemption model on a preemptive linux kernel?

['drc...@google.com' via golang-nuts]

>From the POV of not-runtime-code, preemption can happen anywhere.  
Certainly with GOMAXPROCS > 1, there is OS preemption, and Go's default 
goroutine preemption is now potentially preemptive in most parts of 
non-runtime functions.
On Monday, December 5, 2022 at 7:12:54 PM UTC-5 ren...@ix.netcom.com wrote:

> I don’t think the analysis by alphadose in the issue you cite is correct. 
> Go added async pre-emption (via signals) and I believe it can preempt a Go 
> thread anywhere but in an internal critical section. Ian would know for 
> sure. It is certainly not only at a function call boundary because that 
> would cause the “infinite spin loop blocking GC” issue. Once a routine is 
> preempted any available routine could run on the same processor/OS thread.
>
> On Dec 5, 2022, at 5:20 PM, Andrew Athan  wrote:
>
> In brief then, in the presence of os threads running on a kernel that can 
> preempt threads, it is incorrect to assume that any two statements within a 
> goroutine will run atomically (both run, or not at all), irrespective of 
> the simplicity of those statements, or whether any function calls involved 
> are inlined, etc...
>
> On Monday, December 5, 2022 at 3:18:09 PM UTC-8 Andrew Athan wrote:
>
>> The statement I made is actually a bit stronger than the one you 
>> confirmed: Even if the goroutines are using atomic load/store, the 
>> preemtive nature of the os threads could easily interrupt one goroutine 
>> between an atomic load and its use of that value, giving another goroutine 
>> the opportunity to change the stored value at the atomic load location, 
>> potentially leading to a data race -- particularly when the loader is 
>> storing to a related but different location and/or without a CAS on the 
>> original loaded value.
>>
>> To answer your question, no ... within the go runtime, I DO NOT claim to 
>> have found instances of that kind of load/check/store as separate 
>> operations within a function such that those operations are assumed to run 
>> atomically.
>>
>> However, I've run into a couple of such instances in public repos. Thus, 
>> I wanted to confirm my thinking. For example, I initiated a discussion 
>> about same here:
>>
>> https://github.com/alphadose/haxmap/issues/26
>>
>> (I ran across haxmap while reviewing issues in the golang repo relative 
>> to sync.Map)
>>
>> On Monday, December 5, 2022 at 10:45:10 AM UTC-8 Ian Lance Taylor wrote:
>>
>>> On Mon, Dec 5, 2022 at 10:03 AM Andrew Athan  wrote: 
>>> > 
>>> > I'm having trouble finding definitive information about golang's 
>>> preemption model when running with GOMAXPROCS>1 on a multi-core Intel with 
>>> preemtive linux kernel. 
>>> > 
>>> > As I understand it, in such a scenario, two goroutines may be 
>>> scheduled by the go runtime onto two separate system threads on two 
>>> separate CPUs. 
>>> > 
>>> > Isn't it true then, that irrespective of whether the two goroutines 
>>> are scheduled onto separate CPUs, the OS may preemptively interrupt either 
>>> of those goroutines to let the other run? Also, that if they are indeed 
>>> scheduled onto separate CPUs, that the memory accesses made by those 
>>> goroutines are interleaved even if no individual goroutine is "preempted"?
>>>  
>>> > 
>>> > I'm asking because in reviewing the code of some "lock free" 
>>> concurrent data structures written in go, it appears the authors have made 
>>> certain assumptions about race conditions (e.g., the code of on goroutine 
>>> assumes that another goroutine won't perform a load/store between two 
>>> function calls the first goroutine makes to check a boolean and store a 
>>> value). 
>>> > 
>>> > Given that goroutines are mappes onto system threads, and that in a 
>>> preemptive kernel those threads may be preempted and/or irrespective of the 
>>> preemptive kernel issue may run on separate cores, no assumptions should be 
>>> made about the "atomicity" of multiple statements in a goroutine relative 
>>> to other goroutines. Right? 
>>> > 
>>> > Where can I get the most current and accurate information about this 
>>> topic? 
>>>
>>> I'm not aware of any detailed documentation of the issues you are 
>>> looking at. So the most current and accurate information is the 
>>> source code. Or this mailing list. 
>>>
>>> You are correct that non-atomic memory operations made by different 
>>> goroutines can be freely interleaved. If there is any code in the 
>>> runtime that assumes otherwise, that code is badly broken. If you can 
>>> point to the specific code that you are concerned about, perhaps we 
>>> can allay your concerns, or perhaps we can fix the bug. 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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/0b44c5d7-7c45-4392-9

[go-nuts] Re: App Engine hasn't upgraded beyond Go 1.16, which is now out of security window

['drc...@google.com' via golang-nuts]

I just checked with my personal app engine project ("gcloud app deploy", 
that's app engine, I think), and with 1.19 specified in go.mod and 
"runtime: 119" in app.yaml, the app reported runtime.Version() of 1.19.3.  
My understanding is this is a recent change.

On Thursday, December 15, 2022 at 11:33:41 AM UTC-5 Olivier Favre wrote:

> Hi,
>
> I think App Engine is not getting as much development efforts as Cloud Run 
> does.
> I foresee it the same fate as Legacy Networks versus VPC.
>
> That said, it looks like they were unconfortable with this situation as 
> they released Go 1.18 and 1.19 (NB: not 1.17) a few days ago:
>
> https://cloud.google.com/appengine/docs/standard/go/release-notes#December_07_2022
>
> Cheers,
> --
> Olivier Favre
>
> On Monday, September 12, 2022 at 11:33:09 AM UTC+2 Rusco wrote:
>
>> Googles own language on Googles own cloud lags behind several version,  I 
>> don't understand this :-( 
>>
>> Microsoft seems to be more eager to keep things up to date: 
>> .NET 7 comes to Azure Functions & Visual Studio 2022 - .NET Blog 
>> (microsoft.com) 
>> 
>>
>> On Monday, 12 September 2022 at 02:33:18 UTC+1 seana...@gmail.com wrote:
>>
>>> I'm hoping a member of the Go team will take pity on me and prod the App 
>>> Engine Go team about this. The most recent upgrade to AE's Go environment 
>>> was in Nov 2021, when they started supporting Go 1.16 (see release notes 
>>> below). Now that Go 1.19 is out, Go 1.16 won't be getting security fixes 
>>> anymore, and App Engine Go users are in a frustrating place.
>>>
>>> If this is App Engine's way of telling me to move to Cloud Run 
>>> (-->Dockerizing), it'd be nice if they'd just tell us that :). Otherwise, 
>>> could a Googler please help us AE users out and poke AE into getting up to 
>>> 1.17, 1.18, or 1.19? I don't know where to file a bug straight against AE, 
>>> and I figure the Go team should be very interested in this, due to 
>>> aforementioned security implications.
>>>
>>> https://cloud.google.com/appengine/docs/standard/go/release-notes
>>>
>>> Thanks,
>>> Sean
>>>
>>

-- 
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/5844eecc-9315-41a7-957e-39c6bd46a0bcn%40googlegroups.com.

Re: [go-nuts] Re: Upgradable RLock

['drc...@google.com' via golang-nuts]

Could you use an applicative data structure? (e.g., a balanced binary tree 
where you allocate a new spine for each insertion/deletion)
That has log N overhead to read, log N storage allocated per write, but I 
think if you CAS the writes, the reads can proceed with a lightweight 
barrier.


On Sunday, February 5, 2023 at 11:45:38 AM UTC-5 Ian Lance Taylor wrote:

> On Sun, Feb 5, 2023, 4:34 AM Juliusz Chroboczek  wrote:
>
>> >> I took some time to put this to a test. The Go program here
>> >> https://go.dev/play/p/378Zn_ZQNaz uses a VERY short holding of the
>> >> lock - but a large % of runtime holding the lock.
>>
>> > Thanks for the benchmark.  You're right: if you have hundreds of
>> > goroutines doing nothing but acquiring a read lock, then an RWMutex
>> > can be faster.  They key there is that there are always multiple
>> > goroutines waiting for the lock.
>>
>> Could you please explain that?  You previously implied that the
>> required atomic operation is going to make the difference between the
>> two kinds of mutex irrelevant, why does the argument not apply here?
>>
>
> If there are enough concurrent lockers to overwhelm the plain mutex spin 
> lock, then the read-write mutex will work better.  My argument is that in 
> real programs that is an unlikely case if the lock is held for a short 
> period of time.
>
> 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/3769f0c0-dc9b-417f-8be0-6113a4fe0090n%40googlegroups.com.

[go-nuts] Re: Building Go 1.21 for openbsd/386

['drc...@google.com' via golang-nuts]

Try also GOMAXPROCS=1 ?  At some point not too long ago we made that dial 
down the concurrency in the compiler (before, it would do concurrent 
builds/compiles anyway) and that should reduce the maximum footprint.
On Wednesday, February 22, 2023 at 1:42:56 PM UTC-5 Jan Mercl wrote:

> The subject target is not distributed by the Go team. Attempting to build 
> if from sources in a qemu 4GB VM [OpenBSD 7.2 (GENERIC.MP) #404: Tue Sep 
> 27 12:54:46 MDT 2022] via
>
> $ GOROOT_BOOTSTRAP=~/go1.19 nohup ./make.bash
>
>   produces
>
> Building Go toolchain1 using /home/jnml/go1.19.
> Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
> Building Go toolchain2 using go_bootstrap and Go toolchain1.
> # cmd/compile/internal/ssa
> fatal error: runtime: out of memory
>
> runtime stack:
> runtime.throw({0x87b8037, 0x16})
> /home/jnml/goroot/src/runtime/panic.go:1047 +0x4d fp=0xcf7c860c 
> sp=0xcf7c85f8 pc=0x80832fd
> runtime.sysMapOS(0x89c0, 0x40)
> /home/jnml/goroot/src/runtime/mem_bsd.go:71 +0x144 fp=0xcf7c8638 
> sp=0xcf7c860c pc=0x805d764
> runtime.sysMap(0x89c0, 0x40, 0x8d4bc10)
> /home/jnml/goroot/src/runtime/mem.go:142 +0x3f fp=0xcf7c8648 
> sp=0xcf7c8638 pc=0x805d59f
> runtime.(*mheap).grow(0x8d3e3e0, 0x9)
> /home/jnml/goroot/src/runtime/mheap.go:1459 +0x2b1 fp=0xcf7c869c 
> sp=0xcf7c8648 pc=0x8073d51
> runtime.(*mheap).allocSpan(0x8d3e3e0, 0x9, 0x0, 0x78)
> /home/jnml/goroot/src/runtime/mheap.go:1191 +0x2f2 fp=0xcf7c872c 
> sp=0xcf7c869c pc=0x8073382
> runtime.(*mheap).alloc.func1()
> /home/jnml/goroot/src/runtime/mheap.go:910 +0x7c fp=0xcf7c8750 
> sp=0xcf7c872c pc=0x8072cfc
> runtime.systemstack()
> /home/jnml/goroot/src/runtime/asm_386.s:370 +0x35 fp=0xcf7c8754 
> sp=0xcf7c8750 pc=0x80b2305
>
> goroutine 4282 [running]:
> ...
>
> Has anyone successfully built this target from sources and can share how 
> to build Go 1.21 for openbsd/386?
>
> Thanks in advance.
>
> -j
>
>

-- 
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/f580ec4c-426b-412e-a161-40be92e3a44en%40googlegroups.com.

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

['drc...@google.com' via golang-nuts]

And if there is a problem, let us know.  Probably around the time 1.21 is 
released we should write up "how to debug this problem if you see it" but 
we've been working on the tools to automate the search if/when such a bug 
appears.

On Saturday, March 25, 2023 at 10:12:43 AM UTC-4 Eli Bendersky wrote:

> On Sat, Mar 25, 2023 at 2:33 AM Amnon  wrote:
>
>> 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
>>
>
> That's correct. You (and everyone else) can play with this GOEXPERIMENT in 
> 1.21 (or now, if using gotip). The most useful thing to do would be to run 
> your tests with this experiment set and see what breaks. 
>
> Looking towards the future, this is also related to the forward 
> compatibility proposal: https://github.com/golang/go/issues/57001
>
> Eli
>
>
>
>  
>
>>
>>
>>
>> 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, &item) } 

 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: &item 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
  
 
 .

>>> -- 
>> 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/aba5e0bd-c676-45f0-a7b7-ce6e23985124n%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/dae0cd5f-9c82-4f39-970d-13bb28860c0en%40googlegroups.com.

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

['drc...@google.com' via golang-nuts]

Based on studying large bodies of existing code, you should be about 25x 
more scared right now that there's an undetected bug in your code from the 
existing semantics -- especially if you haven't written many tests.  If 
this change does cause a failure in existing code, we have a tool to help 
isolate it down to the line, still working on the end-user/programmer 
packaging for that tool but it is based on one we used internally for 
compiler debugging.

On Tuesday, April 4, 2023 at 2:57:58 AM UTC-4 Marcello H wrote:

> The "scary" thing is, that if people don't have enough tests, they are 
> probably not aware of such a bug, or can they still be aware somehow?
>
> Op maandag 3 april 2023 om 20:19:33 UTC+2 schreef drc...@google.com:
>
>> And if there is a problem, let us know.  Probably around the time 1.21 is 
>> released we should write up "how to debug this problem if you see it" but 
>> we've been working on the tools to automate the search if/when such a bug 
>> appears.
>>
>> On Saturday, March 25, 2023 at 10:12:43 AM UTC-4 Eli Bendersky wrote:
>>
>>> On Sat, Mar 25, 2023 at 2:33 AM Amnon  wrote:
>>>
 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

>>>
>>> That's correct. You (and everyone else) can play with this GOEXPERIMENT 
>>> in 1.21 (or now, if using gotip). The most useful thing to do would be to 
>>> run your tests with this experiment set and see what breaks. 
>>>
>>> Looking towards the future, this is also related to the forward 
>>> compatibility proposal: https://github.com/golang/go/issues/57001
>>>
>>> Eli
>>>
>>>
>>>
>>>  
>>>



 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, &item) } 
>>
>> 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: &item 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
>>  
>> 
>> .
>>
> -- 
 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/aba5e0bd-c676-45f0-a7b7-ce6e23985124n%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/f81cf3a2-acf3-4f19-aa00-5107ebaf1105n%40googlegroups.com.

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

['drc...@google.com' via golang-nuts]

Have you considered moving to another platform, either Lemmy or Kbin?
(He says, not having completed his own move of the benchmarking bot to 
botsin.space).
On Saturday, June 24, 2023 at 1:51:10 PM UTC-4 Robert Engels wrote:

> I’m fairly certain Reddit will license those tools for moderators use. 
> That is not what they are trying to prevent. 
>
> > On Jun 24, 2023, at 8:39 AM, Wojciech S. Czarnecki  
> wrote:
> > 
> > Dnia 2023-06-23, o godz. 23:50:32
> > Amnon  napisał(a):
> > 
> >> Sorry, but I have been away and missed the context.
> > 
> >> What is the protest about?
> > 
> > Reddit's decision to sink all good free tools that allow people (mods) 
> to work several hours per day
> > keeping their communities free of propaganda and scams.
> > 
> >> 
> >> What has redit changed?
> > 
> > APIs that were free to access by third parties will be priced as gold.
> > 
> >> Thanks
> > yw.
> > 
> > P.S.
> > It is worth mentioning that Reddit *has* a good reason to close APIs 
> that are abused by A"I" businesses.
> > Just there is no will to make such changes robust, IMO, as it would 
> cost. It seems to me that current Reddit's
> > brass has no faintest idea how many $millions monthly mod's work is 
> worth.
> > 
> > -- 
> > 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...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/20230624153919.43160eba%40xmint
> .
>

-- 
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/479f9d06-a8ee-4a06-9a02-82ff14c9c767n%40googlegroups.com.

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

['drc...@google.com' via golang-nuts]

"Vote with YOUR feet, not MY feet".

On Monday, June 26, 2023 at 12:56:12 PM UTC-4 Thomas Bushnell BSG wrote:

> I mean, this is mostly true, except that the protesters do have the right 
> to administer the subreddit in the way they choose, as long as they are the 
> admins.
>
> As you said, if you don't like that, you are of course free to use a 
> different site. But it seems a bit off-kilter to say "if you don't like it, 
> vote with your feet", while complaining about the actions some other users 
> of the site have taken, and not voting with your feet.
>
> Thomas
>
>
> On Fri, Jun 23, 2023 at 4: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 other users. That's my
>> right and I expect it to be equally respected.
>>
>> PS: I'm paying $7/month to Reddit to have r/golang ad-free. May I ask
>> you for a refund? Thanks for your consideration.
>>
>> -- 
>> 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-UU-fvBis8XZuOobK_6wW44iOddAzni1KRF9udHH-ELtg%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/0e948ef0-f715-40d5-acec-aadbdbaa47d9n%40googlegroups.com.

[go-nuts] Re: Can a lambda passed to other functions be inlined by a Go compiler?

['drc...@google.com' via golang-nuts]

The short answer is yes, but not in this example.

In your example the inline doesn't happen because `foo` is (barely) too 
complex so it is not inlined and the closure remains a parameter:
```
go build -gcflags=-m=2 main.go
# command-line-arguments
./main.go:3:6: cannot inline foo: function too complex: cost 82 exceeds 
budget 80
./main.go:13:6: cannot inline main: function too complex: cost 87 exceeds 
budget 80
./main.go:15:12: can inline main.func1 with cost 6 as: func(int) bool { 
return v % 2 == 0 }
./main.go:4:16: make([]int, 0, len(data)) escapes to heap:
./main.go:4:16:   flow: {heap} = &{storage for make([]int, 0, len(data))}:
./main.go:4:16: from make([]int, 0, len(data)) (non-constant size) at 
./main.go:4:16
./main.go:3:10: data does not escape
./main.go:3:22: suitable does not escape
./main.go:4:16: make([]int, 0, len(data)) escapes to heap
./main.go:14:15: []int{...} does not escape
./main.go:15:12: func literal does not escape
```

I simplified your `foo` to take result as a parameter, and that did the job:
```
go build -gcflags=-m=2 main.go
# command-line-arguments
./main.go:3:6: can inline foo with cost 74 as: func([]int, []int, func(int) 
bool) []int { for loop; return result }
./main.go:12:6: cannot inline main: function too complex: cost 113 exceeds 
budget 80
./main.go:15:20: can inline main.func1 with cost 6 as: func(int) bool { 
return v % 2 == 0 }
./main.go:15:5: inlining call to foo
./main.go:15:5: inlining call to main.func1
./main.go:3:16: parameter result leaks to ~r0 with derefs=0:
./main.go:3:16:   flow: ~r0 = result:
./main.go:3:16: from return result (return) at ./main.go:9:2
./main.go:3:10: data does not escape
./main.go:3:16: leaking param: result to result ~r0 level=0
./main.go:3:30: suitable does not escape
./main.go:14:16: make([]int, 0, len(data)) escapes to heap:
./main.go:14:16:   flow: {heap} = &{storage for make([]int, 0, len(data))}:
./main.go:14:16: from make([]int, 0, len(data)) (non-constant size) at 
./main.go:14:16
./main.go:13:15: []int{...} does not escape
./main.go:14:16: make([]int, 0, len(data)) escapes to heap
./main.go:15:20: func literal does not escape
```
You can examine the output either with `-S`
```
go build -gcflags=-S main.go > main.asm
```
or with `GOSSAFUNC=main`
```
GOSSAFUNC=main go build main.go
# runtime
dumped SSA for main,1 to ../../src/inline-lam/ssa.html
# command-line-arguments
dumped SSA for main,1 to ./ssa.html
```
and in either case you will see that the call to foo and the closure are 
gone.

With PGO ( https://go.dev/doc/pgo ) if that function (foo) is on a hot 
path, it is more likely to get inlined and thus allow the closure inlining.
(and if it's not on a hot path, do you care?)

On Monday, October 23, 2023 at 12:19:51 PM UTC-4 Shamil Mukhetdinov wrote:

> Imagine you have something like this:
>
> * func foo(data []int, suitable func(v int) bool) []int { *
> *   result := make([]int, 0, len(data) *
> *for _, v := range data { *
> *if suitable(v) { *
> *result = append(result, v) *
> *} *
> *} return result *
> *} *
>
>
> func main() { 
> data := []int{1, 2, 3, 4, 5} 
> foo(data, func(v int) bool { return v % 2 == 0 }) 
> }
>
> If instead of suitable lambda I use an explicit function call, that call 
> may be inlined in Go.
>
> But C++ supporting inlining for copied closures.
>
> Does golang support inlining for lambdas, if I have that function 
> signature? Or only non-escaping to the other functions lambdas can be 
> inlined?
>
> I found this issue which is still open
>

-- 
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/fee35c70-d93a-4b6d-9106-b8286372cb4bn%40googlegroups.com.