Re: [go-nuts] go install, replace directive any ongoing discussions?

[Paul Jolly]

>> I missed the conversation originally. however go install has been left in a 
>> unfortunate state where it bewilderingly errors out when the main module 
>> contains a replace directive.
>
> This sounds like a bug. I would file an issue with an easy reproduction case.

Erroring on replace directives is an intentional decision for now:
https://github.com/golang/go/issues/40276#issue-659471259

But might be relaxed in the future:

> Parts of this proposal are more strict than is technically necessary (for
> example, requiring one module, forbidding replace directives). We could relax
> these restrictions without breaking compatibility in the future if it seems
> expedient. It would be much harder to add restrictions later.

If you think this is a valid case for requiring non-directory replace
directives to be applied, then I suggest raising an issue with some
details.

-- 
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/CACoUkn7-b91t0oSNHpYQzUqr9apj9Zo14aXX0dEMd-5dK%3DkhPQ%40mail.gmail.com.

Re: [go-nuts] go install, replace directive any ongoing discussions?

['Axel Wagner' via golang-nuts]

On Sun, Mar 7, 2021 at 3:45 AM James Lawrence  wrote:

> I missed the conversation originally. however go install has been left in
> a unfortunate state where it bewilderingly errors out when the main module
> contains a replace directive.
>

This sounds like a bug. I would file an issue with an easy reproduction
case.


> I'm primarily wondering where I should be going to contribute to that
> conversation and if there is someone on the go team I can just file a few
> experience reports with around package tooling over the past few release.
> as the go tools have seemingly become less user friendly over the past few
> releases. its mainly a bunch of varied issues.
>

You can post them here - either by posting them on a blog or something and
linking, or writing them here verbatim. Many people on the Go team are
reading this list.


> --
> 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/c421a1a9-5215-45f9-9a95-ef7b19485e25n%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/CAEkBMfFz1vu1s47U%2By3VAm6eKLUJ7PqfVphbf%2BiaLw31mzXHdg%40mail.gmail.com.

[go-nuts] go install, replace directive any ongoing discussions?

[James Lawrence]

I missed the conversation originally. however go install has been left in a 
unfortunate state where it bewilderingly errors out when the main module 
contains a replace directive. I'm primarily wondering where I should be 
going to contribute to that conversation and if there is someone on the go 
team I can just file a few experience reports with around package tooling 
over the past few release. as the go tools have seemingly become less user 
friendly over the past few releases. its mainly a bunch of varied issues.

-- 
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/c421a1a9-5215-45f9-9a95-ef7b19485e25n%40googlegroups.com.

Re: [go-nuts] should I pass functions as parameter of a go routine?

[Max Renaud]

In your second example, the address of wg doesn't change with each 
iteration so you can use:
for _, onedoer := range d {
go func(od *doer) {
od.do()
}(onedoer)
}
https://play.golang.org/p/A1dAUuyvg9T


On Thursday, March 4, 2021 at 8:50:19 AM UTC-8 Julien Pivotto wrote:

> Thank you for your quick answer, it is of a great help.
>
> have a nice day.
>
> On Thursday, March 4, 2021 at 5:11:40 PM UTC+1 axel.wa...@googlemail.com 
> wrote:
>
>> Interesting question. I think the code is fine. From the spec 
>> :
>>
>> > The function value and parameters are evaluated as usual in the calling 
>> goroutine, but unlike with a regular call, program execution does not wait 
>> for the invoked function to complete.
>>
>> This means `onedoer.do` is immediately evaluated, before the loop 
>> continues. The usual issue with loops is due to closures. So, this would be 
>> wrong and have exactly the issue you are worried about:
>>
>> for _, onedoer := range d {
>> go func() { oneoder() }
>> }
>>
>> But the go statement isn't equivalent to that, it doesn't close over the 
>> function value, it evaluates it.
>>
>> On Thu, Mar 4, 2021 at 5:01 PM Julien Pivotto  
>> wrote:
>>
>>> Hello,
>>>
>>> In the following example: https://play.golang.org/p/yz_ifHC-Hut
>>>
>>> for _, onedoer := range d {
>>>   go onedoer.do()
>>> }
>>>
>>> Should I pass the function onedoer.do as a parameter of the go routine:  
>>> https://play.golang.org/p/WHPahoayDbM ?
>>>
>>> for _, onedoer := range d {
>>>   go func(od *doer, w *sync.WaitGroup) {
>>> od.do(w)
>>>   }(onedoer, )
>>> }
>>>
>>> I am wondering if `go func()` could return before figuring out which 
>>> function to run, creating a race with the loop.
>>>
>>>
>>> Thanks 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/6547c92f-a009-4fd4-abb2-801b2c44ea67n%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/a9aecf32-556d-4b3f-862f-0f979e6194d8n%40googlegroups.com.

Re: [go-nuts] Incompatibility of reflection libraries (reflect versus go-reflect), on json-iterator (Go 1.15.8)

[Yan Titarenko]

CC'ing to Mikko/Justin/taowen/Johannes/Aaron. In case if they would be
interested to explain about reflect2's usage.

I tried to patch rook - and here is what I got:

https://github.com/advancedwebdeveloper/rook
https://gist.github.com/advancedwebdeveloper/52be86fa92fd9ed484ef26f5cbfc541c

pkg/apis/ceph.rook.io/v1/cluster.go:40:77: undefined: reflect2.DeepEqual

This is not with gollvm:

$ go version
> go version go1.16 linux/arm64


I could re-check with gollvm.

I can tell that I haven't found any build errors, when I patched rook, on
behalf of go-reflect. So it could allow to do some benchmarking - we could
compare with reflect's performance.



On Thu, Mar 4, 2021 at 5:01 AM Sokolov Yura  wrote:

> I use reflect2 in our custom more robust deepcopy implementation in two
> places:
>
> 1. When I need to grow slice.
> Standard reflect package has no way to enlarge slice without call to
> reflect.MakeSlice, which allocates unneeded slice header.
> 2. When I need to iterate map.
> Using standard reflect package there is no way to iterate map[string]int
> without allocation of string header and int for every key-value pair. When
> key or values is struct, things become worse.
> Also reflect2.UnsafeMap.UnsafeSetIndex is just a wrapper call to
> mapassign. Yes, it is unsafe in the meaning it doesn't check types, but it
> is ok in
> this place because I've checked types a bit earlier.
>
> This two things give a lot for performance (and allocation-less-ness) of
> our deepcopy.
>
> Yura
>
> вторник, 2 марта 2021 г. в 21:18:51 UTC+3, Ian Lance Taylor:
>
>> On Tue, Mar 2, 2021 at 5:49 AM Yan Titarenko
>>  wrote:
>> >
>> > On Friday, February 26, 2021 at 5:50:44 PM UTC+2 Ian Lance Taylor
>> wrote:
>> >>
>> >>
>> >> OK, but the reflect package generally does not allocate, so what is
>> >> the advantage of reflect2? Are there benchmarks showing where
>> >> reflect2 is significantly faster?
>> >
>> >
>> > The problem is in the fact that benchmarking of json-iterator is itself
>> a package specific one.
>> >
>> > This is not like if we could take 10-15 packages, which use reflect
>> package, to benchmark those. And we could each of the end-user Go projects,
>> to make it work with reflect2 - and run the same benchmark. Then we could
>> patch again, to target go-reflect. Then we could do benchmarking again.
>>
>> I agree that in general its better to use larger scale benchmarks.
>> That said, for a case like this, if reflect2 is faster, it must be
>> possible to show that in a micro-benchmark, perhaps one that uses
>> b.ReportAllocs.
>>
>> But really I'm just trying to get at a basic fact. Right now I don't
>> understand in what way reflect2 is faster, and the package docs don't
>> tell me that either. Do you know?
>>
>>
>>
>> >> (I'll note that while this may not be a good idea for the overall
>> >> ecosystem, I expect that it is possible to port reflect2 to support
>> >> gccgo/GoLLVM.)
>> >
>> >
>> > In that case it would be critical to resolve these issues:
>> > https://github.com/modern-go/reflect2/issues/16
>> > . Should those methods and types be referenced? perhaps something else
>> should be used?
>> > Or it should - but we would have to implement the missing ones?
>> >
>> > btw this is what never being answered, during all the previous
>> discussions.
>>
>> I'm sorry, I'm not answering the question because it doesn't really
>> make sense to me. There is no gccgo/GoLLVM version of a function like
>> resolveTypeOff. The fix to make reflect2 work with gccgo/GoLLVM is
>> not to add resolveTypeOff to gccgo/GoLLVM. It's to change the
>> reflect2 package to work with the gccgo/GoLLVM versions of the reflect
>> types.
>>
>> The gccgo/GoLLVM reflect types are just different from the gc reflect
>> types. This doesn't mean that reflect2 can't support gccgo/GoLLVM,
>> but it does mean that the package needs to be modified to support
>> those types, using appropriate build constraints.
>>
>>
>> > It might make sense to really work on various reflections APIs - to
>> learn why it is typically grow into a situation when alternatives are
>> written.
>> > Perhaps it makes sense to react on various issues and demands, of
>> libgo, earlier then the whole Go package (for reflection, in this case)
>> would be formed?
>> > At least it would be clear that is not reasonable to spend time on
>> designing/implementing an alternative, compared to patching libgo's
>> package.
>> > Also is a "corner edge" case, with json-iterator - it would give some
>> disadvantages, in case of other end-user Go package. And that is what
>> authors of such "alternative" do not want to deal with - so reflect2 is,
>> unsurprisingly, unmaintained even by the original author.
>>
>> I would certainly be happy to patch libgo if someone can tell me what
>> should change. This gets us back to the benchmark discussion.
>>
>> Ian
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this