On Fri, Jun 4, 2021 at 11:53 PM Amnon wrote:
>
> How about renaming your vendor directory to something else?
That is not really an option because it is not "my" vendor directory.
For example, there is a lot of Ruby code in this repository, which
some people install with 'bundle install
https://golang.org/issue/9859 is a proposal to support such syntax, but it
hasn't really moved in a long time.
On Monday, June 7, 2021 at 2:47:07 AM UTC-7 axel.wa...@googlemail.com wrote:
> What we are saying is that you are misremembering. That's not how Go ever
> worked.
>
> On Mon, Jun 7,
FWIW I do not get the same result:
goos: windows
goarch: amd64
cpu: AMD Phenom(tm) II X4 830 Processor
BenchmarkFilter3-4599912 1902 ns/op 0
B/op 0 allocs/op
BenchmarkFilter4-4569143 2118 ns/op 0
B/op 0
FWIW I do tend to mix value and pointer receivers occasionally.
Sometimes a type needs a pointer receiver in one method, but a different
method doesn't and it's more convenient to have a copy available for
temporary operations.
Usually when I implement flag.Var, I make `Set` use a pointer receiver
The code: https://play.golang.org/p/DxUj6kBqf8k
The Filter4 function has one more assignment statement than Filter3.
But the benchmark result shows Filter4 is faster than Filter3.
The result:
cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
BenchmarkFilter3-43575656 980.2 ns/op
Thank a lot, this is the topic what I'm interested in.
Current syntax has troubled me in many cases.
在2021年6月7日星期一 UTC+8 下午10:35:47 写道：
> https://golang.org/issue/9859 is a proposal to support such syntax, but
> it hasn't really moved in a long time.
>
> On Monday, June 7, 2021 at 2:47:07 AM
There is no good reason that proper behavior should be dependent on
understanding best practices. It should help with readability not correctness.
Seems to me the compiler or Go Vet should prohibit this - in my review of the
stdlib and other projects I can’t see any reason why it doesn’t.
>
name time/op
Filter3-4 1.38µs ± 0%
Filter4-4 1.39µs ± 0%
On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>
> The code: https://play.golang.org/p/DxUj6kBqf8k
>
> The Filter4 function has one more assignment statement than Filter3.
> But the benchmark result shows
On Mon, Jun 7, 2021 at 9:16 AM FallingFromBed wrote:
>
> Newbie: Where I can get to see Go routines' white paper and its
> implementation ( Header file equivalent) in Go Repo'?
I'm not sure what you mean by a white paper, but I doubt that it
exists. Also, Go does not have header files or
I think that is my point. The methods in the code I shared have a proper
receiver type based on the requirements of the methods. It only “breaks” in the
context of the usage which isn’t at all obvious.
So it seems to me that go lint should at least complain that a struct has
mutating methods
Hi all, I want to know are there any telco grade open source policy frame
work orchestration projects based on the golang.
If anyone has got information on this, please share with me.
Thanks and Regards
N.M.Trivedi
--
*STL - Sterlite Technologies Limited Disclaimer:*
The content of this
Newbie: Where I can get to see Go routines' white paper and its
implementation ( Header file equivalent) in Go Repo'?
Thanks,
FFB
--
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
Hello everyone,
I am trying to understand *debug/elf* package especially method *Symbols()*
. I was wondering if there's any way to determine whether symbol name or
address of symbol is closest to elf symbol or DSO load address. I am
relatively new to the package so sorry for any silly
On Mon, Jun 7, 2021 at 9:16 AM Iti Shree wrote:
>
> I am trying to understand debug/elf package especially method Symbols() . I
> was wondering if there's any way to determine whether symbol name or address
> of symbol is closest to elf symbol or DSO load address. I am relatively new
> to the
* 'Axel Wagner' via golang-nuts [210607 10:19]:
> FWIW I do tend to mix value and pointer receivers occasionally.
> Sometimes a type needs a pointer receiver in one method, but a different
> method doesn't and it's more convenient to have a copy available for
> temporary operations.
Axel, I
On Mon, Jun 7, 2021 at 7:42 PM Robert Engels wrote:
> I think that is my point. The methods in the code I shared have a proper
> receiver type based on the requirements of the methods.
>
No, they don't. The `Log` method requires a pointer receiver, as it
accesses state that is supposed to be
Go does a good job of making it easy to do the right thing, especially in tests
(such as parallel benchmarks or setting env variables), and avoiding the need
for tricks like package level variables or noinline directives seems a useful
feature.
On Mon, 7 Jun 2021, at 4:47 PM, peterGo wrote:
>
Not a white paper per se, but there are a few resources by Dmitry Vyukov
that i came about:
A Talk: https://youtu.be/-K11rY57K7k
The Slides:
Ian,
I don't know whether it is feasible. It is unnecessary.
A benchmark should be treated as a scientific experiment. If we do that
with Paul's benchmarks and write them in scientific form, then we get the
expected results.
$ benchstat xpt.txt
name
* Robert Engels [210607 21:18]:
> (I think you pasted the wrong link - that is my code).
subsequent correction acknowledged; assuming the following discussion is
about https://play.golang.org/p/-f73t_Pm7ur
> It is not about being unwilling to admit it. Your
> explanation/reasoning has not
i7-7500U
name time/op
Filter3-4 1.38µs ± 0%
Filter4-4 1.39µs ± 0%
i5-8250U
name time/op
Filter3-8 1.37µs ± 0%
Filter4-8 1.39µs ± 0%
On Monday, June 7, 2021 at 7:42:43 PM UTC-4 tapi...@gmail.com wrote:
> On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote:
>
>> name
On Tue, Jun 8, 2021 at 1:26 AM Robert Engels wrote:
> The pattern of a background stats collector is a common one. The atomic is
> required not optional.
>
It might be a common pattern, but it uses a pointer-receiver in that case.
The atomic operation is not required, it operates on a local
On Mon, Jun 7, 2021 at 11:42 PM Robert Engels wrote:
> I don’t think that represents the problem fairly. In the non interface
> case I know I can’t accept a copy so I would declare the method as taking a
> pointer to the struct.
>
How methods are declared should, in general, not be a matter of
The pattern of a background stats collector is a common one. The atomic is
required not optional.
> On Jun 7, 2021, at 6:16 PM, 'Axel Wagner' via golang-nuts
> wrote:
>
>
> BTW, just to nail down the point of that code being wrong without interfaces:
> Your usage of `atomic` in `Log` is
We agree. It needs a pointer receiver to work. The atomic is also needed in
this case for background logging.
The problem in this case is that recordEvents() has to document that the
EventLogger passed to recordEvents() must have a pointer receiver for the Log()
method. There is nothing in
BTW, just to nail down the point of that code being wrong without
interfaces: Your usage of `atomic` in `Log` is superfluous. You are
operating on a local variable, so there is no possibility of concurrent
modification. Your code is equivalent to this:
https://play.golang.org/p/zYG0zTsk-2a
The
I think that is why it is inconsistent and obtuse to me. The Log() method
doesn’t need a pointer receiver. It works fine without it. It only needs a
pointer receiver because when passed to a function declared as taking an
interface a copy is made (and a reference to the copy held). This copy
* 'Axel Wagner' via golang-nuts [210607 19:06]:
> Well, it seems a bad idea to say that interfaces are implicitly pointers
> then. That seems to indicate that Rob's original phrasing is indeed an
> important clarification - the language behaves as if the value contained in
> them is copied when
Sorry - correct link. I missed the subtle change.
> On Jun 7, 2021, at 8:18 PM, Robert Engels wrote:
>
>
> (I think you pasted the wrong link - that is my code).
>
> It is not about being unwilling to admit it. Your explanation/reasoning has
> not convinced me.
>
> Imagine some library
I don’t think that represents the problem fairly. In the non interface case I
know I can’t accept a copy so I would declare the method as taking a pointer to
the struct.
With interfaces this is lost - as the interface is implicitly a pointer - but
whether it points to a copy or the original
On Sun, Jun 6, 2021 at 4:19 AM xie cui wrote:
>
> https://github.com/golang/go/blob/master/src/runtime/mgc.go#L858-L876
> due to these code lines, stw in one gc cycle may happen more than 2 times. so
> stw times in one gc cycle could be 2(general), 3, 4, and even for ever?
Theoretically,
On Tue, Jun 8, 2021 at 1:25 AM Robert Engels wrote:
> I think that is why it is inconsistent and obtuse to me. The Log() method
> doesn’t need a pointer receiver. It works fine without it.
>
I don't understand how you can continue to say that. I've linked the code
several times. It does not
On Monday, June 7, 2021 at 1:01:49 PM UTC-4 peterGo wrote:
> name time/op
> Filter3-4 1.38µs ± 0%
> Filter4-4 1.39µs ± 0%
>
>
What is your CPU model?
>
> On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> The code: https://play.golang.org/p/DxUj6kBqf8k
>>
On Tue, Jun 8, 2021 at 2:05 AM Robert Engels wrote:
>
> We agree. It needs a pointer receiver to work. The atomic is also needed
> in this case for background logging.
>
> The problem in this case is that recordEvents() has to document that the
> EventLogger passed to recordEvents() must have a
(I think you pasted the wrong link - that is my code).
It is not about being unwilling to admit it. Your explanation/reasoning has not
convinced me.
Imagine some library declares the EventLogger interface as shown. Acceptable.
Someone writes the RecordEvents() method taking an EventLogger.
Does anyone konw which proposal changes the access for embeded field name
of struct？
Eg:
```
type Base struct{
Name string
}
type Value struct{
Base
}
```
We initial a Value as:
var v = Value{
Base: Base{
Name:"xxx",
}
}
instead of
var v = Value{
Name:"xxx",
}
I
I don't understand the question. This has always been how the language
worked, all the way back to Go 1.0 at least. As far as I'm aware.
Embedding only effects selector expressions and methods sets - i.e. it
allows you to write `v.Name` instead of writing `v.Base.Name`. It doesn't
affect
On Mon, Jun 7, 2021 at 11:20 AM Ally Dale wrote:
> I want to know why golang change the access method.
The name of the programming language is Go.
> Anyone who knows the isssue link, please reply me. Thanks a lot.
There's no proposal and there's no issue. It always worked like that.
You
As far as I remember(maybe I have missing something),
var v = Value{
Name:"xxx",
}
Is the old way to initial an embeded field.
Some issuse changes the way of this.
I can't find the original discussion.
在2021年6月7日星期一 UTC+8 下午5:28:27 写道：
> I don't understand the question. This has always
What we are saying is that you are misremembering. That's not how Go ever
worked.
On Mon, Jun 7, 2021 at 11:36 AM Ally Dale wrote:
> As far as I remember(maybe I have missing something),
> var v = Value{
> Name:"xxx",
> }
> Is the old way to initial an embeded field.
> Some issuse
Would it be feasible for the Go tool to disable inlining and deadcode
elimination of code within the bodies of Benchmarks and Tests? Not the code
under test of course. It could be as crude as disabling these optimizations for
files in _test.go files.
On Sun, 6 Jun 2021, at 1:33 PM, Paul S.
41 matches
Mail list logo
