Re: [go-nuts] go cycle reference type - what's the practical usage of decls like "type T *T" and similars?

[messi...@gmail.com]

Thanks Ian, the state machine case reminds me of a video by Rob 
Pike: https://www.youtube.com/watch?v=HxaD_trXwRE , put the link here to 
help others who are interested :-)

On Tuesday, March 16, 2021 at 12:58:00 PM UTC+8 Ian Lance Taylor wrote:

> On Mon, Mar 15, 2021 at 9:23 PM messi...@gmail.com
>  wrote:
> >
> > In file cycles.src there're many type declarations to demo cycle 
> reference, some are invalid and some are valid, I can understand why 
> invalid ones are invalid, but for some of the valid ones, I cannot figure 
> out their usage scenarios, take some as examples:
> >
> > type T *T // Does nil the only value a type T variable/const can hold?
> >
> > or with bigger cycle:
> > type ( // The same with above T for all T1, T2 and T3?
> > T1 T2
> > T2 *T3
> > T3 T1
> > )
>
> I'm not aware of any practical use for this. However, in Go we try to
> aim for simplicity and orthogonality where possible, even if that
> permits writing code that is not particularly useful. Rather than
> write a special rule like "pointer types may not be a loop," we simply
> permit it to work and avoid having another rule in the language.
>
> There is an amusing use of this kind of type in
> https://golang.org/test/peano.go, but it's not intended to be
> practical or useful.
>
>
> > or function type decl like:
> >
> > F func(F) F
> >
> > I'm wondering whether type decls like this do have practical usage, or 
> just for grammar learning?
>
> Types like
>
> type F func() F
>
> on the other hand, are useful for state machines. The idea is that
> the current state of some operation is expressed in the form of a
> function, and every call to the state function returns a function that
> implements the next state. There is an example of this at
> https://golang.org/src/text/template/parse/lex.go#L105.
>
> 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/1ed7651f-8288-4f08-b5ad-d909f7bb5f53n%40googlegroups.com.

Re: [go-nuts] go cycle reference type - what's the practical usage of decls like "type T *T" and similars?

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 9:23 PM messi...@gmail.com
 wrote:
>
> In file cycles.src there're many type declarations to demo cycle reference, 
> some are invalid and some are valid, I can understand why invalid ones are 
> invalid, but for some of the valid ones, I cannot figure out their usage 
> scenarios, take some as examples:
>
> type T *T // Does nil the only value a type T variable/const can hold?
>
> or with bigger cycle:
> type ( // The same with above T for all T1, T2 and T3?
> T1 T2
> T2 *T3
> T3 T1
> )

I'm not aware of any practical use for this.  However, in Go we try to
aim for simplicity and orthogonality where possible, even if that
permits writing code that is not particularly useful.  Rather than
write a special rule like "pointer types may not be a loop," we simply
permit it to work and avoid having another rule in the language.

There is an amusing use of this kind of type in
https://golang.org/test/peano.go, but it's not intended to be
practical or useful.


> or function type decl like:
>
> F func(F) F
>
> I'm wondering whether type decls like this do have practical usage, or  just 
> for grammar learning?

Types like

type F func() F

on the other hand, are useful for state machines.  The idea is that
the current state of some operation is expressed in the form of a
function, and every call to the state function returns a function that
implements the next state.  There is an example of this at
https://golang.org/src/text/template/parse/lex.go#L105.

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/CAOyqgcXqKAYSLxgj%2BuZfsdgqet%3Dk7F%2BW33a4WYSTb7aXpB7UZg%40mail.gmail.com.

[go-nuts] go cycle reference type - what's the practical usage of decls like "type T *T" and similars?

[messi...@gmail.com]

Hi,

In file cycles.src 

 there're 
many type declarations to demo cycle reference, some are invalid and some 
are valid, I can understand why invalid ones are invalid, but for some of 
the valid ones, I cannot figure out their usage scenarios, take some as 
examples:

type T *T // Does nil the only value a type T variable/const can hold?

or with bigger cycle:
type ( // The same with above T for all T1, T2 and T3?
T1 T2
T2 *T3
T3 T1
)

or function type decl like:

F func(F) F

I'm wondering whether type decls like this do have practical usage, or  
just for grammar learning?

Thanks a lot.

-- 
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/2711edc7-e8d3-442f-b1ae-942daf134d71n%40googlegroups.com.

Re: [go-nuts] running tests against benchmarks

[Jeremy French]

Nice!  Thanks.

On Mon, Mar 15, 2021 at 10:36 PM Wojciech S. Czarnecki 
wrote:

> Dnia 2021-03-15, o godz. 10:44:50
> Jeremy French  napisał(a):
>
> > So it seems like the logical solution would be to create a test that
> runs a
> > benchmark and makes sure the benchmark results are within some
> acceptable
> > range.  I realize that benchmarks are going to differ from machine to
> > machine, or based on CPU load, etc.
>
> Compare old implementation and new one:
> https://play.golang.org/p/w9giDccrpNa
>
> PS. In a CI pipeline, as we do not know exact HW where tests will run
> tomorrow, we
> normalize to a known base. Usually crypto/des suits well as the stable
> unit of speed.
>
>
> 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/CA%2Bj6mhD_o%3DGmUbrN5dbWAka4Vow%2BnTJ1hNpJU4%2B-M-XNSJ%3DdAA%40mail.gmail.com.

Re: [go-nuts] running tests against benchmarks

[Wojciech S. Czarnecki]

Dnia 2021-03-15, o godz. 10:44:50
Jeremy French  napisał(a):

> So it seems like the logical solution would be to create a test that runs a 
> benchmark and makes sure the benchmark results are within some acceptable 
> range.  I realize that benchmarks are going to differ from machine to 
> machine, or based on CPU load, etc. 

Compare old implementation and new one: https://play.golang.org/p/w9giDccrpNa

PS. In a CI pipeline, as we do not know exact HW where tests will run tomorrow, 
we
normalize to a known base. Usually crypto/des suits well as the stable unit of 
speed.


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/20210316033610.3841d8a7%40xmint.

Re: [go-nuts] is func schedule always run on g0's stack?

[Ian Lance Taylor]

Yes.

-- 
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/CAOyqgcWM4aGXEGjhe4n_R4UJjHDE%3D%2B8Dbyco-JaqviaF2y7yRw%40mail.gmail.com.

Re: [go-nuts] Re: Does current GC move object now?

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 10:26 PM rmfr  wrote:
>
> Maybe the reason for such a strict rule on using cgo is just to take 
> precautions if our GC moves object in the future? And at that time, the 
> syscall implementation must be rewritten to add some codes to pinning the 
> objects used by each syscall from being moved. Am I correct?

Yes, exactly.  There are special rules for syscall, and the Go project
promises that syscall will keep working, including pinning pointers,
and internal pointers, that are passed to syscalls.

Ian


> On Sunday, March 14, 2021 at 2:11:18 PM UTC+8 rmfr wrote:
>>
>> I am watching the implementation of syscall `writev` from 
>> [here](https://github.com/golang/sys/blob/bd2e13477e9c63125302cd9da2d61879c6aa1721/unix/zsyscall_linux.go#L1641),
>>  and comparing it with the 
>> [proposal](https://github.com/golang/proposal/blob/master/design/12416-cgo-pointers.md)
>>  of cgo. I found the rule applies on cgo and syscall is inconsistent.
>>
>> If the object could be moved during GC, then the code to implement `writev` 
>> is incorrect. Because GC could happen during the syscall and the byte slices 
>> kernel is using has been moved! :-(
>>
>> If the object may not be moved during GC, then the code to implement syscall 
>> `writev` is correct. But from the perspective of go runtime, cgo is just a 
>> kind of special "syscall", then the rule applies to cgo now is far too 
>> strict -- you simply couldn't call a C API like `writev` which takes array 
>> of byte slices as input arg (because the rule applies on cgo now only allow 
>> one input arg contains at most one go pointer).
>>
>> Maybe I have missed something, please correct me. Thanks a lot for your 
>> patient and kindness :-)
>
> --
> 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/57c3f2e9-e28c-43e3-b765-b33434b6d1f5n%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/CAOyqgcUBUgw55HMMDp68mSZPhHCyRBjoL9di%3DGffrUBmB_L6bQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Robert Engels]

Very well said. 

> On Mar 15, 2021, at 7:04 PM, Jeremy French  wrote:
> 
> I was really trying not to weigh in here, mostly because it's a decision 
> that has been decided, so there's not a lot of point in continuing the 
> discussion, and yesterday it seemed like the thread would die, yet... it 
> continues.
> 
> For context, I was against the generics proposal, primarily because it would 
> make *my* life more complicated, while not providing *me* that much benefit.  
> I raised the concerns I had, especially in regards to the "if you don't like 
> it, don't use it" arguments. I participated in a couple conversations on this 
> mailing list.  In the end, I was fairly convinced that there were others in 
> the community (and the community as a whole) who would benefit from the 
> change far more than what it would cost me, and resigned myself to the change.
> 
> All of that is just to establish my bona fides.  If I were inclined to be 
> biased on this topic, it would be against the Go team, not in their favor.  
> 
> And yet, I can say unequivocally that any suggestion that the Go team has 
> railroaded this proposal through, or has ignored the concerns of its user 
> base, is pure fiction.  Every single concern or question I've seen raised has 
> been addressed respectfully and at face value - even, I would say - several 
> concerns or complaints on this side of the argument that perhaps reasonably 
> could have been scoffed at or dismissed as just stupid.  They have been 
> respectful and attentive at every turn.  I don't necessarily agree or like 
> the decision they made, but these character assassinations against them or 
> implications that they are subject to corruption from their corporate parent 
> have no supporting evidence that I've seen, including any presented in this 
> thread.
> 
> It seems pretty clear that they are passionate about the health and longevity 
> of the project, and are in the unenviable position of having to make a 
> decision that is guaranteed to make some people angry no matter what they 
> decide.  But in the end, it is their call to make, and they made it the best 
> way they could think of to do so.  You can't ask any more than that.
> 
>> On Monday, March 15, 2021 at 6:14:36 PM UTC-4 Ian Lance Taylor wrote:
>> On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com  wrote: 
>> > 
>> > I am in favor of the proposal but I think that accounting for popularity 
>> > votes is not a good measure of things. 
>> > A lot of people are at various stages of their technical journey in 
>> > computer science and engineering and there has to be a weight given to the 
>> > more technical opinions that is not reflected in the github 
>> > upvote/downvote system. 
>> > At one point, everyone would have upvoted that the earth was flat. 
>> > 
>> > Just a note in passing :) 
>> 
>> Yes. I am not saying that the proposal was adopted because it had 
>> good support. I am arguing against the suggestion that the proposal 
>> should not have been adopted because it had a lot of critics. 
>> 
>> Ian 
>> 
>> 
>> > On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote: 
>> >> 
>> >> On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote: 
>> >> > 
>> >> > > For example, the multiple proposals that flowed out of 
>> >> > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
>> >> >  
>> >> > None of them have been adopted. 
>> >> > 
>> >> > I remember what was happening to "try" error handling proposal. It was 
>> >> > withdrawn only because of active resistance by the community. 
>> >> > 
>> >> > And what's happened to a new "generics" proposal, it also got a lot of 
>> >> > critics but was "accepted" in less than a month after formal 
>> >> > publication on github. As Russ said "No change in consensus". What does 
>> >> > it mean? Who are these people who can change the consensus? How was it 
>> >> > measured? A few days after Russ locked it, so nobody can even say a 
>> >> > word against it if they wanted. So it looks very much that company 
>> >> > management learned from "try" proposal. 
>> >> 
>> >> The design draft was put up for discussion for months before it became 
>> >> a formal proposal. It was not new. 
>> >> 
>> >> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs 
>> >> up and 123 thumbs down (and ten "confused"). Yes, there were critics. 
>> >> But I think it is fair to say that the proposal has far more 
>> >> supporters than critics. 
>> >> 
>> >> The "no change in consensus" comment refers to the discussion after 
>> >> the proposal was moved to "likely accept" status: 
>> >> https://github.com/golang/go/issues/43651#issuecomment-772744198. 
>> >> After it was marked as "likely accept", there was no change to the 
>> >> consensus that it should be accepted. (Note that the "likely accept" 
>> >> comment got 60 thumbs up and 0 thumbs down (and one "confused").) 
>> >> 
>> >> None of this is anything like the "try" 

Re: [go-nuts] How to call a C `writev` styled library api via cgo without allocation and copying of the whole byte slice vector?

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 6:25 AM rmfr  wrote:
>
> Say here is a C api like `ssize_t writev(const struct iovec *iov, int 
> iovcnt)` which the definition of iovec is like below:
>
> ```
> struct iovec {
>  uint8_t   *Base;  /* Base address. */
>  uint64_t Len;/* Length. */
>  };
> ```
>
> For C api which like `ssize_t write(const void *buf, size_t nbyte)`, the 
> solution would be quite straight forward:
>
> ```
> bs := make([]byte, 1024*1024*512)
> // without extra memory allocation and copying of the whole input byte slice 
> :-D
> rc := C.write(unsafe.Pointer([0]), C.int(len(bs)))
> ```
>
> But how to call C `writev` style API without extra memory allocation or 
> copying of the whole byte slice vector?
>
> ```
> bsv := make([][]byte, 1024)
> for i := range bsv{
> bsv[i] = make([]byte, 5*1024*(rand.Intn(i)+1))
> }
> // assuming that allocation of a iovec array is acceptable
> // but allocation and copying of all bsv[x] byte slice member is unacceptable
> //
> iovec := make([]syscall.Iovec, len(bsv))
> for i := range bsv {
> bs := bsv[i]
> if len(bs) > 0 {
> iovec[i].Base = unsafe.Pointer([0])
> iovec[i].Len = uint64(len(bs))
> }
> }
> //
> // rc := C.writev( /* how? :-( */)
> rc := C.writev(unsafe.Pointer([0]), C.int(len(iovec))) // Does this 
> code is right and safe?
> ```
>
> Does the code above is right?
>
> I have read cgo's docs carefully, and here is a constraint from 
> https://golang.org/cmd/cgo/#hdr-Passing_pointers:
>
> > Go code may pass a Go pointer to C provided the Go memory to which it 
> > points does not contain any Go pointers.
>
> If the Go memory pointed by `unsafe.Pointer([0])` contains pointer 
> which points to these byte slice members of bsv, so it would be a violation 
> of the cgo constraint above. And that means you could not call C `writev` 
> style API without allocation and copying of the whole vector.
>
> Please correct me if I get something wrong. Thanks a lot :-D


I think that everything you wrote is correct.

In some cases you may be able to work around this problem by creating
the byte slices in memory allocated using C.malloc.

Or, in some cases you can use https://golang.org/pkg/net/#Buffers to
get Go to call writev for you.

But I don't think there is any good solution for the general case.

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

Re: [go-nuts] Re: Error running gollvm on Ubuntu 20.04

[Khanh TN]

Hi Ian,
This problem is somewhat resolved for me now. Gollvm works perfectly in my 
fresh installed Debian.
Maybe Go and Gollvm has some conflicts in my previous build or Ubuntu got 
some problem.
Thanks a lot for your help.

Khanh

On Tuesday, March 16, 2021 at 7:53:34 AM UTC+8 Ian Lance Taylor wrote:

> On Sat, Mar 13, 2021 at 4:51 PM Khanh TN  wrote:
> >
> > Hi, Ian,
> > It does look like importing golang.org/x/sys/unix causes the problem
> > A simple go program like
> >
> > package main
> >
> > import (
> > "fmt"
> > "golang.org/x/sys/unix"
> > )
> >
> > func main() {
> > fmt.Println("Hello, World!")
> > fmt.Println(unix.Getpagesize())
> > }
> >
> > does cause the same error as before. This file builds and runs fine with 
> my normal Go but gives that error with Gollvm. If I do not include unix, 
> Gollvm does work though.
> > What do you suggest?
>
> This sounds like a bug somewhere between LLVM and gold. You should
> probably file a bug report against gold (at
> https://sourceware.org/bugzilla). I don't know why nobody else has
> reported this.
>
> You may be able to make progress by using lld. I don't know; I've
> never tried it myself.
>
> 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/338aa677-170d-4d3b-afbd-3dc4fd94ba31n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Jeremy French]

I was really trying not to weigh in here, mostly because it's a decision 
that has been decided, so there's not a lot of point in continuing the 
discussion, and yesterday it seemed like the thread would die, yet... it 
continues.

For context, I was against the generics proposal, primarily because it 
would make *my* life more complicated, while not providing *me* that much 
benefit.  I raised the concerns I had, especially in regards to the "if you 
don't like it, don't use it" arguments. I participated in a couple 
conversations on this mailing list.  In the end, I was fairly convinced 
that there were others in the community (and the community as a whole) who 
would benefit from the change far more than what it would cost me, and 
resigned myself to the change.

All of that is just to establish my bona fides.  If I were inclined to be 
biased on this topic, it would be against the Go team, not in their favor.  

And yet, I can say unequivocally that any suggestion that the Go team has 
railroaded this proposal through, or has ignored the concerns of its user 
base, is pure fiction.  Every single concern or question I've seen raised 
has been addressed respectfully and at face value - even, I would say - 
several concerns or complaints on this side of the argument that perhaps 
reasonably could have been scoffed at or dismissed as just stupid.  They 
have been respectful and attentive at every turn.  I don't necessarily 
agree or like the decision they made, but these character assassinations 
against them or implications that they are subject to corruption from their 
corporate parent have no supporting evidence that I've seen, including any 
presented in this thread.

It seems pretty clear that they are passionate about the health and 
longevity of the project, and are in the unenviable position of having to 
make a decision that is guaranteed to make some people angry no matter what 
they decide.  But in the end, it is their call to make, and they made it 
the best way they could think of to do so.  You can't ask any more than 
that.

On Monday, March 15, 2021 at 6:14:36 PM UTC-4 Ian Lance Taylor wrote:

> On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com  wrote:
> >
> > I am in favor of the proposal but I think that accounting for popularity 
> votes is not a good measure of things.
> > A lot of people are at various stages of their technical journey in 
> computer science and engineering and there has to be a weight given to the 
> more technical opinions that is not reflected in the github upvote/downvote 
> system.
> > At one point, everyone would have upvoted that the earth was flat.
> >
> > Just a note in passing :)
>
> Yes. I am not saying that the proposal was adopted because it had
> good support. I am arguing against the suggestion that the proposal
> should not have been adopted because it had a lot of critics.
>
> Ian
>
>
> > On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote:
> >>
> >> On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote:
> >> >
> >> > > For example, the multiple proposals that flowed out of
> >> > 
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
> .
> >> > None of them have been adopted.
> >> >
> >> > I remember what was happening to "try" error handling proposal. It 
> was withdrawn only because of active resistance by the community.
> >> >
> >> > And what's happened to a new "generics" proposal, it also got a lot 
> of critics but was "accepted" in less than a month after formal publication 
> on github. As Russ said "No change in consensus". What does it mean? Who 
> are these people who can change the consensus? How was it measured? A few 
> days after Russ locked it, so nobody can even say a word against it if they 
> wanted. So it looks very much that company management learned from "try" 
> proposal.
> >>
> >> The design draft was put up for discussion for months before it became
> >> a formal proposal. It was not new.
> >>
> >> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
> >> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
> >> But I think it is fair to say that the proposal has far more
> >> supporters than critics.
> >>
> >> The "no change in consensus" comment refers to the discussion after
> >> the proposal was moved to "likely accept" status:
> >> https://github.com/golang/go/issues/43651#issuecomment-772744198.
> >> After it was marked as "likely accept", there was no change to the
> >> consensus that it should be accepted. (Note that the "likely accept"
> >> comment got 60 thumbs up and 0 thumbs down (and one "confused").)
> >>
> >> None of this is anything like the "try" proposal
> >> (https://golang.org/issue/32437), which had 318 thumbs up and 794
> >> thumbs down (and 132 "confused").
> >>
> >> Ian
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "golang-nuts" group.
> > To unsubscribe from this group and 

Re: [go-nuts] Re: Error running gollvm on Ubuntu 20.04

[Ian Lance Taylor]

On Sat, Mar 13, 2021 at 4:51 PM Khanh TN  wrote:
>
> Hi, Ian,
> It does look like importing golang.org/x/sys/unix causes the problem
> A simple go program like
>
> package main
>
> import (
>  "fmt"
>  "golang.org/x/sys/unix"
> )
>
> func main() {
>fmt.Println("Hello, World!")
>fmt.Println(unix.Getpagesize())
> }
>
> does cause the same error as before. This file builds and runs fine with my 
> normal Go but gives that error with Gollvm. If I do not include unix, Gollvm 
> does work though.
> What do you suggest?

This sounds like a bug somewhere between LLVM and gold.  You should
probably file a bug report against gold (at
https://sourceware.org/bugzilla).  I don't know why nobody else has
reported this.

You may be able to make progress by using lld.  I don't know; I've
never tried it myself.

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/CAOyqgcVm2mu3CNgxAVOV9ivuET%3DiutYJ_CBo%2BeQ4wVgk2eH-CQ%40mail.gmail.com.

Re: [go-nuts] struct conversion, new fields, and incompatibility

['Colin Arnott' via golang-nuts]

Sweet, I will open up the proposal, unless there is mass descent to this
idea.

I will call out that this WILL make implementing marshaling logic harder,
but it seems orthogonal to the desire for a vet check to prevent random
code breakage.

On Mon, 15 Mar 2021, 23:31 Ian Lance Taylor,  wrote:

> It may be worth noting that we already have a vet check for composite
> literals that verifies that if a composite literal is used with a
> struct defined in a different package, then the fields are explicitly
> named.  This check means that adding fields to a struct will never
> break composite literals in other packages.  This corresponds to this
> comment in
> https://urldefense.proofpoint.com/v2/url?u=https-3A__golang.org_doc_go1compat=DwIBaQ=ncDTmphkJTvjIDPh0hpF_w=OaiRsMTFeJ0tMmMJQ5CwMuxNMvWoKXAJr-ebE3c5HU8=BwDgsUE5_LEEW5RxBIHVgubBBU6sjTmHByGINoQdumY=eo85CA9Hql7PSY99KGPgRBnHzFithGMWr8rpoxoSLeY=
> :
>
> Struct literals. For the addition of features in later point
> releases, it may be necessary to add fields to exported structs in the
> API. Code that uses unkeyed struct literals (such as pkg.T{3, "x"}) to
> create values of these types would fail to compile after such a
> change. However, code that uses keyed literals (pkg.T{A: 3, B: "x"})
> will continue to compile after such a change. We will update such data
> structures in a way that allows keyed struct literals to remain
> compatible, although unkeyed literals may fail to compile. (There are
> also more intricate cases involving nested data structures or
> interfaces, but they have the same resolution.) We therefore recommend
> that composite literals whose type is defined in a separate package
> should use the keyed notation.
>
> I think it would be consistent with that to add a vet check that would
> warn about attempts to convert a struct defined in a different package
> to a locally defined struct.
>
> Ian
>
> --
> 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/oAjxpH-Qq2Y/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/CAOyqgcXejyPtRM-sUN_JkcsP24Y2dqfPeqdensbOzmpbKF9r5Q%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/CADJfOyXCBew7_W7pkzvmst4GWraXh_i6FRYQsQLivTRmw%2BPS2g%40mail.gmail.com.

Re: [go-nuts] struct conversion, new fields, and incompatibility

[Ian Lance Taylor]

It may be worth noting that we already have a vet check for composite
literals that verifies that if a composite literal is used with a
struct defined in a different package, then the fields are explicitly
named.  This check means that adding fields to a struct will never
break composite literals in other packages.  This corresponds to this
comment in https://golang.org/doc/go1compat:

Struct literals. For the addition of features in later point
releases, it may be necessary to add fields to exported structs in the
API. Code that uses unkeyed struct literals (such as pkg.T{3, "x"}) to
create values of these types would fail to compile after such a
change. However, code that uses keyed literals (pkg.T{A: 3, B: "x"})
will continue to compile after such a change. We will update such data
structures in a way that allows keyed struct literals to remain
compatible, although unkeyed literals may fail to compile. (There are
also more intricate cases involving nested data structures or
interfaces, but they have the same resolution.) We therefore recommend
that composite literals whose type is defined in a separate package
should use the keyed notation.

I think it would be consistent with that to add a vet check that would
warn about attempts to convert a struct defined in a different package
to a locally defined struct.

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/CAOyqgcXejyPtRM-sUN_JkcsP24Y2dqfPeqdensbOzmpbKF9r5Q%40mail.gmail.com.

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

[Robert Engels]

I think it is more of using a specialized compiler on unmodified C code and 
expecting it to work. 

> On Mar 15, 2021, at 3:58 PM, Andy Balholm  wrote:
> 
> 
> By the way, this existed at one point. Early versions of the Go toolchain 
> included C compilers (6c, 8c, etc.) designed to work together nicely with Go 
> code. If I remember right, most of the Go runtime was written in C, and 
> compiled with these compilers. But they used an unusual dialect of C (which 
> came from Plan 9) instead of ANSI C, so they couldn't compile most C 
> libraries.
> 
> When the Go runtime was translated from C to Go, these compilers were 
> dropped. 
> 
> If you wanted to revive them and make them ANSI compliant, you would need to 
> write a new libc that calls into the Go standard library for its system 
> calls—because C code compiled with this compiler would not be able to call 
> into the system libc without CGo!
> 
> Andy
> 
> On 3/13/21 10:57 PM, Jason E. Aten wrote:
>> I was noodling about how to minimize the cost of crossing the CGO barrier 
>> from Go code into C code and back.
>> 
>> Then I thought, what if I look at this the other way around.
>> 
>> Instead of teaching the Go compiler how to better run C code, what if a C 
>> compiler (e.g. clang) was taught to generate code that used the Go stack and 
>> calling conventions.
>> 
>> Theoretically, the cc output "in Go convention" could be linked with Go code 
>> without paying the CGO penalty, no?
>> 
>> How crazy is 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/028ecd62-5f9f-4cb6-95df-a0b48ff3d825n%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/bf013837-7b1c-6cb3-801f-03776ec5cdd4%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/EC0175FF-2F70-4D8F-BC78-6D144F6E5D5F%40ix.netcom.com.

Re: [go-nuts] Error while executing exec.command

['Axel Wagner' via golang-nuts]

I would also suggest to just use os.ReadFile
, instead of executing `cat`. The
latter is pointless overhead and unnecessarily fragile.

On Mon, Mar 15, 2021 at 11:40 PM Amit Saha  wrote:

>
>
> On Tue, 16 Mar 2021, 9:37 am Sharan Guhan,  wrote:
>
>> Hi Experts,
>>
>> I am relatively new to GOLANG and trying a simple program as below which
>> is failing in fetching the output of a file, which works otherwise on the
>> command prompt:
>>
>> Lang : GOLANG
>> OS : Linux/Centos
>> Problem : Using exec.command to get the output of a certain file
>> Error: Getting no such file or directory error:
>>
>> command = fmt.Sprintf("cat /sys/bus/pci/devices/%s.0/numa_node",
>> name)
>>
>> *2021/03/15 11:55:59 fork/exec cat
>> /sys/bus/pci/devices/:19:00.0/numa_node: no such file or directory*
>> *exit status 1*
>>
>> However, the same executed on linux prompt works from the same working
>> directory as the code :
>> *[root-v05 ~]# cat /sys/bus/pci/devices/:19:00.0/numa_node*
>> *0*
>> [root-v05 ~]#
>>
>>
>> Please suggest what I may be missing.
>>
>
> The exec.Command() expects the arguments to be passed separately. The
> problem you are having here is that it is thinking your entire command
> along with the arguments is assumed to be the command to execute.
>
> I would have a look at the documentation for exec.Command
>
>
>
>> Sharan
>>
>>
>>
>> --
>> 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/c5f6d10b-e857-4652-ac94-0e200233db9dn%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/CANODV3n5WzwQ8j7bmCjruGU%3DbG%2BXdE1-mSQBxrx0O8CfcaJvLw%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/CAEkBMfGOPEhuPkv-HxwnzyYpUFfp-1%3DiAy60TLgwfVmcnDkjPg%40mail.gmail.com.

Re: [go-nuts] Error while executing exec.command

[Amit Saha]

On Tue, 16 Mar 2021, 9:37 am Sharan Guhan,  wrote:

> Hi Experts,
>
> I am relatively new to GOLANG and trying a simple program as below which
> is failing in fetching the output of a file, which works otherwise on the
> command prompt:
>
> Lang : GOLANG
> OS : Linux/Centos
> Problem : Using exec.command to get the output of a certain file
> Error: Getting no such file or directory error:
>
> command = fmt.Sprintf("cat /sys/bus/pci/devices/%s.0/numa_node",
> name)
>
> *2021/03/15 11:55:59 fork/exec cat
> /sys/bus/pci/devices/:19:00.0/numa_node: no such file or directory*
> *exit status 1*
>
> However, the same executed on linux prompt works from the same working
> directory as the code :
> *[root-v05 ~]# cat /sys/bus/pci/devices/:19:00.0/numa_node*
> *0*
> [root-v05 ~]#
>
>
> Please suggest what I may be missing.
>

The exec.Command() expects the arguments to be passed separately. The
problem you are having here is that it is thinking your entire command
along with the arguments is assumed to be the command to execute.

I would have a look at the documentation for exec.Command



> Sharan
>
>
>
> --
> 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/c5f6d10b-e857-4652-ac94-0e200233db9dn%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/CANODV3n5WzwQ8j7bmCjruGU%3DbG%2BXdE1-mSQBxrx0O8CfcaJvLw%40mail.gmail.com.

[go-nuts] Error while executing exec.command

[Sharan Guhan]

Hi Experts,

I am relatively new to GOLANG and trying a simple program as below which is 
failing in fetching the output of a file, which works otherwise on the 
command prompt:

Lang : GOLANG
OS : Linux/Centos
Problem : Using exec.command to get the output of a certain file
Error: Getting no such file or directory error:

command = fmt.Sprintf("cat /sys/bus/pci/devices/%s.0/numa_node", 
name)

*2021/03/15 11:55:59 fork/exec cat 
/sys/bus/pci/devices/:19:00.0/numa_node: no such file or directory*
*exit status 1*

However, the same executed on linux prompt works from the same working 
directory as the code :
*[root-v05 ~]# cat /sys/bus/pci/devices/:19:00.0/numa_node*
*0*
[root-v05 ~]# 


Please suggest what I may be missing.

Sharan



-- 
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/c5f6d10b-e857-4652-ac94-0e200233db9dn%40googlegroups.com.

[go-nuts] How to implement localhost proxy which injects Proxy-Authorization header to incoming request and sends it to another remote proxy with Go?

[Hugo Bollon]

Hi!
I'm actually building an automation tool based on Selenium with Go called 
IGopher and I have had a few requests to implement native proxy support.  
However, I am facing an issue with those with authentication...  
I can't send the proxy credentials to Chrome and without them it asks 
through an alert box for authentication that I can hardly interact with 
through Selenium (I'm not even sure it's possible in headless mode) .

So I thought of an intermediary proxy system hosted locally by my program 
which will add the *Proxy-Authorization* header and transfer the request to 
the remote proxy:

[image: IGopher_proxies.jpg]

Something like this:  proxy-login-automator 


I'm not very familiar with proxies to be honest, but I tried this approach 
using *NewSingleHostReverseProxy*: 
```go
var (
localServerHost  string
remoteServerHost string
remoteServerAuth string
)

// ProxyConfig store all remote proxy configuration
type ProxyConfig struct {
IP   string `yaml:"ip"`
Port int`yaml:"port"`
Username string `yaml:"username"`
Password string `yaml:"password"`
Enabled  bool   `yaml:"activated"`
}

func PrintResponse(r *http.Response) error {
logrus.Infof("Response: %+v\n", r)
return nil
}

// LaunchForwardingProxy launch forward server used to inject proxy 
authentication header
// into outgoing requests
func LaunchForwardingProxy(localPort uint16, remoteProxy ProxyConfig) error 
{
localServerHost = fmt.Sprintf("localhost:%d", localPort)
remoteServerHost = fmt.Sprintf(
"http://%s:%d;,
remoteProxy.IP,
remoteProxy.Port,
)
remoteServerAuth = fmt.Sprintf(
"%s:%s",
remoteProxy.Username,
remoteProxy.Password,
)

remote, err := url.Parse(remoteServerHost)
if err != nil {
panic(err)
}

proxy := httputil.NewSingleHostReverseProxy(remote)
d := func(req *http.Request) {
logrus.Infof("Pre-Edited request: %+v\n", req)
// Inject proxy authentication headers to outgoing request into new Header
basicAuth := "Basic " + 
base64.StdEncoding.EncodeToString([]byte(remoteServerAuth))
req.Header.Set("Proxy-Authorization", basicAuth)
logrus.Infof("Edited Request: %+v\n", req)
logrus.Infof("Scheme: %s, Host: %s, Port: %s\n", req.URL.Scheme, 
req.URL.Host, req.URL.Port())
}
proxy.Director = d
proxy.ModifyResponse = PrintResponse
http.ListenAndServe(localServerHost, proxy)

return nil
}
```

With this code snippet, I'm able to intercept the request and update the 
header. 
However, resending the CONNECT request fails with the following output:

```
INFO[0028] Pre-Edited request: &{Method:CONNECT URL://google.com:443 
Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 
Header:map[Proxy-Connection:[Keep-Alive] User-Agent:[curl/7.68.0]] 
Body: GetBody: ContentLength:0 TransferEncoding:[] Close:false 
Host:google.com:443 Form:map[] PostForm:map[] MultipartForm: 
Trailer:map[] RemoteAddr:127.0.0.1:35610 RequestURI:google.com:443 
TLS: Cancel: Response: ctx:0xc000164300}  function=func1 
line=59

INFO[0028] Edited Request: &{Method:CONNECT URL://google.com:443 
Proto:HTTP/1.1 ProtoMajor:1 ProtoMinor:1 
Header:map[Proxy-Authorization:[Basic ] Proxy-Connection:[Keep-Alive] 
User-Agent:[curl/7.68.0]] Body: GetBody: ContentLength:0 
TransferEncoding:[] Close:false Host:google.com:443 Form:map[] 
PostForm:map[] MultipartForm: Trailer:map[] RemoteAddr:127.0.0.1:35610 
RequestURI:google.com:443 TLS: Cancel: Response: 
ctx:0xc000164300}  function=func1 line=63

INFO[0028] Scheme: , Host: google.com:443, Port: 443 function=func1 
line=64

*2021/03/15 21:35:11 http: proxy error: unsupported protocol scheme ""*
```

What am I doing wrong? Is there a way to send a CONNECT request without 
scheme in Go?
Maybe I'm doing something wrong or my approach to this problem is wrong. 
Are there better methods to achieve my goals?

If you have an idea to complete what I did or any other method, please let 
me know! :)

You can find all IGopher sources here: GitHub repository 
 (Proxy stuff excluded)

-- 
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/ededf8bc-f42d-4ee1-bad4-4ef690549f8dn%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 3:11 PM atd...@gmail.com  wrote:
>
> I am in favor of the proposal but I think that accounting for popularity 
> votes is not a good measure of things.
> A lot of people are at various stages of their technical journey in computer 
> science and engineering and there has to be a weight given to the more 
> technical opinions that is not reflected in the github upvote/downvote system.
> At one point, everyone would have upvoted that the earth was flat.
>
> Just a note in passing :)

Yes.  I am not saying that the proposal was adopted because it had
good support.  I am arguing against the suggestion that the proposal
should not have been adopted because it had a lot of critics.

Ian


> On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote:
>>
>> On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote:
>> >
>> > > For example, the multiple proposals that flowed out of
>> > https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
>> > None of them have been adopted.
>> >
>> > I remember what was happening to "try" error handling proposal. It was 
>> > withdrawn only because of active resistance by the community.
>> >
>> > And what's happened to a new "generics" proposal, it also got a lot of 
>> > critics but was "accepted" in less than a month after formal publication 
>> > on github. As Russ said "No change in consensus". What does it mean? Who 
>> > are these people who can change the consensus? How was it measured? A few 
>> > days after Russ locked it, so nobody can even say a word against it if 
>> > they wanted. So it looks very much that company management learned from 
>> > "try" proposal.
>>
>> The design draft was put up for discussion for months before it became
>> a formal proposal. It was not new.
>>
>> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
>> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
>> But I think it is fair to say that the proposal has far more
>> supporters than critics.
>>
>> The "no change in consensus" comment refers to the discussion after
>> the proposal was moved to "likely accept" status:
>> https://github.com/golang/go/issues/43651#issuecomment-772744198.
>> After it was marked as "likely accept", there was no change to the
>> consensus that it should be accepted. (Note that the "likely accept"
>> comment got 60 thumbs up and 0 thumbs down (and one "confused").)
>>
>> None of this is anything like the "try" proposal
>> (https://golang.org/issue/32437), which had 318 thumbs up and 794
>> thumbs down (and 132 "confused").
>>
>> 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/932a39b7-be1b-4c15-b7c8-f99fce730b0en%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/CAOyqgcUx7T3A4orhbDtY79Ubq%3DJryPM7ZwtdcJhb9q8oyDGS7A%40mail.gmail.com.

[go-nuts] Re: encoding/html package to generate html markup programmatically

[atd...@gmail.com]

Oh, you might be my savior ! :)
I starred it and am going to look into it. Looks quite promising!

On Monday, March 15, 2021 at 6:52:58 PM UTC+1 michael...@gmail.com wrote:

> goht  might be what you're 
> looking for.
>
> On Sunday, March 14, 2021 at 7:36:52 PM UTC-4 atd...@gmail.com wrote:
>
>> Hi,
>>
>> I am currently thinking about implementing SSR for a Go client-side 
>> framework.
>> Not only that but I would like to be able to create static html from the 
>> same code I use to create dynamic  wasm-based webapps.
>>
>> I was trying to find a package that would enable me to generate an html 
>> document but seems like none exists.
>>
>> Do you think it is possible to use encoding/xml to create an xhtml 
>> document?
>>
>>
>> That would allow me to create something like MarkupPy that would replace 
>> js DOM created element by html element.
>>
>>

-- 
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/c74ad520-5e62-4697-b06a-e77272ac3365n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[atd...@gmail.com]

I am in favor of the proposal but I think that accounting for popularity 
votes is not a good measure of things.
A lot of people are at various stages of their technical journey in 
computer science and engineering and there has to be a weight given to the 
more technical opinions that is not reflected in the github upvote/downvote 
system.
At one point, everyone would have upvoted that the earth was flat.

Just a note in passing :)

On Monday, March 15, 2021 at 11:03:50 PM UTC+1 Ian Lance Taylor wrote:

> On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote:
> >
> > > For example, the multiple proposals that flowed out of
> > 
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
> .
> > None of them have been adopted.
> >
> > I remember what was happening to "try" error handling proposal. It was 
> withdrawn only because of active resistance by the community.
> >
> > And what's happened to a new "generics" proposal, it also got a lot of 
> critics but was "accepted" in less than a month after formal publication on 
> github. As Russ said "No change in consensus". What does it mean? Who are 
> these people who can change the consensus? How was it measured? A few days 
> after Russ locked it, so nobody can even say a word against it if they 
> wanted. So it looks very much that company management learned from "try" 
> proposal.
>
> The design draft was put up for discussion for months before it became
> a formal proposal. It was not new.
>
> The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
> up and 123 thumbs down (and ten "confused"). Yes, there were critics.
> But I think it is fair to say that the proposal has far more
> supporters than critics.
>
> The "no change in consensus" comment refers to the discussion after
> the proposal was moved to "likely accept" status:
> https://github.com/golang/go/issues/43651#issuecomment-772744198.
> After it was marked as "likely accept", there was no change to the
> consensus that it should be accepted. (Note that the "likely accept"
> comment got 60 thumbs up and 0 thumbs down (and one "confused").)
>
> None of this is anything like the "try" proposal
> (https://golang.org/issue/32437), which had 318 thumbs up and 794
> thumbs down (and 132 "confused").
>
> 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/932a39b7-be1b-4c15-b7c8-f99fce730b0en%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 5:08 AM Space A.  wrote:
>
> > For example, the multiple proposals that flowed out of
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md.
> None of them have been adopted.
>
> I remember what was happening to "try" error handling proposal. It was 
> withdrawn only because of active resistance by the community.
>
> And what's happened to a new "generics" proposal, it also got a lot of 
> critics but was "accepted" in less than a month after formal publication on 
> github. As Russ said "No change in consensus". What does it mean? Who are 
> these people who can change the consensus? How was it measured? A few days 
> after Russ locked it, so nobody can even say a word against it if they 
> wanted. So it looks very much that company management learned from "try" 
> proposal.

The design draft was put up for discussion for months before it became
a formal proposal.  It was not new.

The formal proposal (https://golang.org/issue/43651) got 1784 thumbs
up and 123 thumbs down (and ten "confused").  Yes, there were critics.
But I think it is fair to say that the proposal has far more
supporters than critics.

The "no change in consensus" comment refers to the discussion after
the proposal was moved to "likely accept" status:
https://github.com/golang/go/issues/43651#issuecomment-772744198.
After it was marked as "likely accept", there was no change to the
consensus that it should be accepted.  (Note that the "likely accept"
comment got 60 thumbs up and 0 thumbs down (and one "confused").)

None of this is anything like the "try" proposal
(https://golang.org/issue/32437), which had 318 thumbs up and 794
thumbs down (and 132 "confused").

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

Re: [go-nuts] No generic, part -2

[Wojciech S. Czarnecki]

Dnia 2021-03-15, o godz. 15:08:22
"Space A."  napisał(a):

> And what's happened to a new "generics" proposal, it also got a lot of 
> critics 

Apparently not that lot. Second (publicized) design was for me, and likely for 
many other "vocal critics", good enough. My personal (and fresh) acceptance 
stems from a simple fact that with current generics proposal I will be able to 
do what I've been doing before with code generators. So there is a clear gain - 
someone who will maintain my code will not be forced to analyze and maintain 
generators.

> A few days after Russ locked it, so nobody can even say a word against it if 
> they wanted. 

On this list, that is not locked by Russ, I do not see "massive disapproval of 
the community". Some people, including me, voiced concerns re expected clutter 
and re worsened legibility. But these are minor disturbances. We just will 
learn to read and visualize new meanings in the code.


-- 
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/20210315225442.2ea013c3%40xmint.

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

[Andy Balholm]

By the way, this existed at one point. Early versions of the Go 
toolchain included C compilers (6c, 8c, etc.) designed to work together 
nicely with Go code. If I remember right, most of the Go runtime was 
written in C, and compiled with these compilers. But they used an 
unusual dialect of C (which came from Plan 9) instead of ANSI C, so they 
couldn't compile most C libraries.


When the Go runtime was translated from C to Go, these compilers were 
dropped.


If you wanted to revive them and make them ANSI compliant, you would 
need to write a new libc that calls into the Go standard library for its 
system calls—because C code compiled with this compiler would not be 
able to call into the system libc without CGo!


Andy

On 3/13/21 10:57 PM, Jason E. Aten wrote:
I was noodling about how to minimize the cost of crossing the CGO 
barrier from Go code into C code and back.


Then I thought, what if I look at this the other way around.

Instead of teaching the Go compiler how to better run C code, what if 
a C compiler (e.g. clang) was taught to generate code that used the Go 
stack and calling conventions.


Theoretically, the cc output "in Go convention" could be linked with 
Go code without paying the CGO penalty, no?


How crazy is 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/028ecd62-5f9f-4cb6-95df-a0b48ff3d825n%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/bf013837-7b1c-6cb3-801f-03776ec5cdd4%40gmail.com.

Re: [go-nuts] running tests against benchmarks

[Jeremy French]

Yes, I thought of something similar.  You could certainly save/write the
results of a benchmark to any version of a db/textfile, and then run
another program to analyze it and do whatever you like with it.  That just
seems like unnecessary overhead.  It would seem that since the test is just
a function with any arbitrary amount or style of code in it, you could
customize it to whatever application-specificity you wanted, if you could
just import the benchmark results without having to run a separate
process.  I don't know, maybe it's just a purity of separation of concerns,
tests are for definitive, yes or no answers, whereas benchmarks are more
prone to human judgment. It just seems like the two pieces I need to do
what I want are sitting right next to each other in my test script.  It
would be nice if they could talk to each other.

On Mon, Mar 15, 2021 at 2:48 PM Marcin Romaszewicz 
wrote:

> What you want to do is common, but it's application-specific enough that
> there aren't so many generalized solutions. What I've always done is create
> a Go program which takes a while to run (I shoot for at least a minute)
> which runs your BeefyFunc in various ways that make sense to you, then I
> make a Jenkins Job which runs it on every commit on fixed hardware, and
> uploads timings to some kind of metrics database like DataDog or
> Prometheus. Both of those have alert triggers on outliers. I realize this
> doesn't help much if you don't have DataDog, Prometheus or Jenkins.
>
> -- Marcin
>
> On Mon, Mar 15, 2021 at 10:45 AM Jeremy French  wrote:
>
>> I keep running into this solution to a particular problem, but when I go
>> to search on how to do it, I find that not only are there seemingly no
>> solutions out there in search-results-land, there doesn't seem to be anyone
>> else even asking about it.  This then leads me to suspect, that I'm going
>> about it in completely the wrong mindset, and I'd appreciate anyone helping
>> me see how everyone else is solving this problem.
>>
>> The issue is this:  Let's say I have some function - call it BeefyFunc()
>> - that is heavily relied upon and executed many times per second in my
>> high-traffic, high-availability critical application.  And let's say that
>> BeefyFunc() is very complex in the sense that it calls many other functions
>> which call other functions, etc, and these called functions are spread out
>> all over the code base, and maintained by a broad and distributed
>> development team (or even just one forgetful, overworked developer).  If
>> BeefyFunc() currently executes at 80 ns/op on my development machine, I
>> want to make sure that no one makes some change to an underlying function
>> which causes BeefyFunc to balloon up to 800 ns/op.  And more to the point,
>> if that ballooning does happen, I want someone to be notified, not to have
>> to rely on a QA person's ability to notice a problem while scanning the
>> benchmark reports.  I want that problem to be highlighted in the same way a
>> test failure would be.
>>
>> So it seems like the logical solution would be to create a test that runs
>> a benchmark and makes sure the benchmark results are within some acceptable
>> range.  I realize that benchmarks are going to differ from machine to
>> machine, or based on CPU load, etc.  But it seems like it would still be
>> useful in a CI/CD situation or on my personal dev machine, where the
>> machine hardware is stable and known and the CPU load can be reasonably
>> predicted, that at least a sufficiently wide range for benchmarks could be
>> reasonably enforced and tested for.
>>
>> Am I being stupid? Or is this a solved problem and it's just my google-fu
>> that's failing me?
>>
>> --
>> 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/7adf598e-03a8-456a-a52f-824a8d1832e3n%40googlegroups.com
>> 
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhBFKyRkPs4mR-2KDxWF29SYbD_zNXQak0emonL630BjJw%40mail.gmail.com.

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

[Robert Engels]

Totally agree and that was my point. If the desire is to speed up calls to C 
there are many options - done explicit (like marking calls non blocking), or 
implicit - once a routine makes a “unknown” C native call that routine is 
always bound to a dedicated thread - clearly you are trading performance for 
other resources in this case. 

I was trying to communicate that if you don’t have to worry about type mapping 
you have some simpler options available than a new C compiler :)

> On Mar 15, 2021, at 2:29 PM, Ian Lance Taylor  wrote:
> 
> On Mon, Mar 15, 2021 at 12:17 PM Jason E. Aten  wrote:
>> 
>>> On Monday, March 15, 2021 at 12:58:38 PM UTC-5 Ian Lance Taylor wrote:
>>> 
>>> I think it is too strong to say that the scheduler is the "bottleneck"
>>> in calling C code, but I believe that the operations required to tell
>>> the scheduler what is happening to the goroutine are the most costly
>>> parts of a call into C code.
>> 
>> 
>> Thanks Ian! I looked through 
>> https://github.com/golang/go/tree/master/src/cmd/cgo but couldn't
>> locate where the CGO communication with the scheduler happens. Could you 
>> point out the code?
> 
> It is in runtime.cgocall, notably the calls to entersyscall and
> exitsyscall.  Also pay attention to runtime.cgocallbackg, which is
> invoked when calling back from C to Go.  Both functions are in
> src/runtime/cgocall.go.  It will help to review the long comment at
> the start of that file.
> 
> 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/CAOyqgcXgvi5DfffbSUHn0WWq4sLtYW4bn7R2hhaDSgoWyvKGeA%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/5DCB6CAA-C957-4B22-8FC7-12594B06E9D5%40ix.netcom.com.

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

[t hepudds]

Hello fellow gophers,

Here is a helpful link that gives an overview of some of what impacts cgo 
performance, including the slides have pointers into the code for anyone 
interested in going deeper:

https://speakerdeck.com/filosottile/why-cgo-is-slow-at-capitalgo-2018 

That was a 2018 presentation “Why cgo is Slow” from Filippo Valsorda from the 
core Go team. (To my knowledge, I don’t know that there is a video of that 
talk, but I’d be curious if anyone has a pointer to a video, including even 
shaky handheld mobile video). 

And here are some quick pointers to some older related issues:

https://github.com/golang/go/issues/42469

https://github.com/golang/go/issues/16051

https://github.com/golang/go/issues/9704

If anyone is feeling curious, benchmarking performance of cgo across Go 
releases could be helpful to spot any slowdowns. For example, someone could run 
this trivial benchmark across recent releases:

https://github.com/golang/go/issues/9704#issuecomment-498812185

Or pick something from here to run across releases:

https://github.com/golang/go/issues/42469#issuecomment-746947396

Or some other benchmark across releases. 

On the scheduler front, I would be curious about this older comment from Ian:

———
“In Go 1.8 when a goroutine calls into C, it is still holding a GOMAXPROCS slot 
and blocking other goroutines from running. Only if it is running in C for more 
than 20 microseconds or so will the system monitor thread decide that it is 
blocked in C code and activate another goroutine. The fact that your system 
performs better than you increase GOMAXPROCS makes me suspect that there is 
something to improve in that area of the code.”
———

 where that comment was later used as part of an explanation FAQ on why 
dqlite moved from Go to C (https://dqlite.io/docs/faq), and whether or not that 
explanation is currently accurate:

———
“The first prototype implementation of dqlite was in Go, leveraging the 
hashicorp/raft implementation of the Raft algorithm. The project was later 
rewritten entirely in C because of performance problems due to the way Go 
interoperates with C: Go considers a function call into C that lasts more than 
~20 microseconds as a blocking system call, in that case, it will put the 
goroutine running that C call in waiting queue and resuming it will effectively 
cause a context switch, degrading performance (since there were a lot of them 
happening).”
———

Regards,
thepudds 

> On Mar 15, 2021, at 3:24 PM, Ian Lance Taylor  wrote:
> 
> On Mon, Mar 15, 2021 at 12:17 PM Jason E. Aten  wrote:
>> 
>>> On Monday, March 15, 2021 at 12:58:38 PM UTC-5 Ian Lance Taylor wrote:
>>> 
>>> I think it is too strong to say that the scheduler is the "bottleneck"
>>> in calling C code, but I believe that the operations required to tell
>>> the scheduler what is happening to the goroutine are the most costly
>>> parts of a call into C code.
>> 
>> 
>> Thanks Ian! I looked through 
>> https://github.com/golang/go/tree/master/src/cmd/cgo but couldn't
>> locate where the CGO communication with the scheduler happens. Could you 
>> point out the code?
> 
> It is in runtime.cgocall, notably the calls to entersyscall and
> exitsyscall.  Also pay attention to runtime.cgocallbackg, which is
> invoked when calling back from C to Go.  Both functions are in
> src/runtime/cgocall.go.  It will help to review the long comment at
> the start of that file.
> 
> Ian
> 
> -- 
> 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/K-If1Wh_6aA/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/CAOyqgcXgvi5DfffbSUHn0WWq4sLtYW4bn7R2hhaDSgoWyvKGeA%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/25FBEE12-FA0D-47FC-A76B-9CD517033A11%40gmail.com.

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

[Ian Lance Taylor]

On Mon, Mar 15, 2021 at 12:17 PM Jason E. Aten  wrote:
>
> On Monday, March 15, 2021 at 12:58:38 PM UTC-5 Ian Lance Taylor wrote:
>>
>> I think it is too strong to say that the scheduler is the "bottleneck"
>> in calling C code, but I believe that the operations required to tell
>> the scheduler what is happening to the goroutine are the most costly
>> parts of a call into C code.
>
>
> Thanks Ian! I looked through 
> https://github.com/golang/go/tree/master/src/cmd/cgo but couldn't
> locate where the CGO communication with the scheduler happens. Could you 
> point out the code?

It is in runtime.cgocall, notably the calls to entersyscall and
exitsyscall.  Also pay attention to runtime.cgocallbackg, which is
invoked when calling back from C to Go.  Both functions are in
src/runtime/cgocall.go.  It will help to review the long comment at
the start of that file.

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/CAOyqgcXgvi5DfffbSUHn0WWq4sLtYW4bn7R2hhaDSgoWyvKGeA%40mail.gmail.com.

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

[Jason E. Aten]

On Monday, March 15, 2021 at 12:58:38 PM UTC-5 Ian Lance Taylor wrote:

> I think it is too strong to say that the scheduler is the "bottleneck" 
> in calling C code, but I believe that the operations required to tell 
> the scheduler what is happening to the goroutine are the most costly 
> parts of a call into C code.
>

Thanks Ian! I looked through 
https://github.com/golang/go/tree/master/src/cmd/cgo but couldn't
locate where the CGO communication with the scheduler happens. Could you 
point out the code?

 

-- 
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/cd368609-f42d-43fa-ab38-6aec43d9cd1dn%40googlegroups.com.

Re: [go-nuts] running tests against benchmarks

[Marcin Romaszewicz]

What you want to do is common, but it's application-specific enough that
there aren't so many generalized solutions. What I've always done is create
a Go program which takes a while to run (I shoot for at least a minute)
which runs your BeefyFunc in various ways that make sense to you, then I
make a Jenkins Job which runs it on every commit on fixed hardware, and
uploads timings to some kind of metrics database like DataDog or
Prometheus. Both of those have alert triggers on outliers. I realize this
doesn't help much if you don't have DataDog, Prometheus or Jenkins.

-- Marcin

On Mon, Mar 15, 2021 at 10:45 AM Jeremy French  wrote:

> I keep running into this solution to a particular problem, but when I go
> to search on how to do it, I find that not only are there seemingly no
> solutions out there in search-results-land, there doesn't seem to be anyone
> else even asking about it.  This then leads me to suspect, that I'm going
> about it in completely the wrong mindset, and I'd appreciate anyone helping
> me see how everyone else is solving this problem.
>
> The issue is this:  Let's say I have some function - call it BeefyFunc() -
> that is heavily relied upon and executed many times per second in my
> high-traffic, high-availability critical application.  And let's say that
> BeefyFunc() is very complex in the sense that it calls many other functions
> which call other functions, etc, and these called functions are spread out
> all over the code base, and maintained by a broad and distributed
> development team (or even just one forgetful, overworked developer).  If
> BeefyFunc() currently executes at 80 ns/op on my development machine, I
> want to make sure that no one makes some change to an underlying function
> which causes BeefyFunc to balloon up to 800 ns/op.  And more to the point,
> if that ballooning does happen, I want someone to be notified, not to have
> to rely on a QA person's ability to notice a problem while scanning the
> benchmark reports.  I want that problem to be highlighted in the same way a
> test failure would be.
>
> So it seems like the logical solution would be to create a test that runs
> a benchmark and makes sure the benchmark results are within some acceptable
> range.  I realize that benchmarks are going to differ from machine to
> machine, or based on CPU load, etc.  But it seems like it would still be
> useful in a CI/CD situation or on my personal dev machine, where the
> machine hardware is stable and known and the CPU load can be reasonably
> predicted, that at least a sufficiently wide range for benchmarks could be
> reasonably enforced and tested for.
>
> Am I being stupid? Or is this a solved problem and it's just my google-fu
> that's failing me?
>
> --
> 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/7adf598e-03a8-456a-a52f-824a8d1832e3n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29LtOaGrUxcg%2BCX82qrqBSdVy417JUrEJxWFR4%2BGV6WD97w%40mail.gmail.com.

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

[Ian Lance Taylor]

On Sun, Mar 14, 2021 at 7:54 PM Robert Engels  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.

Go uses a cooperative goroutine scheduler; even the signal based
preemption that we use now amounts to a mechanism for telling the
goroutine to cooperate.  A goroutine that is running C code is not
cooperating with the scheduler.  If the scheduling code is not aware
of that, it is easy for a blocking C function to block the entire
program, even if there are other runnable goroutines.

I think it is too strong to say that the scheduler is the "bottleneck"
in calling C code, but I believe that the operations required to tell
the scheduler what is happening to the goroutine are the most costly
parts of a call into C code.

I should clarify that I am not saying that this is some inherent
problem that can't be fixed.  I'm saying that this is true in today's
implementation.  If we want to speed up calls to C code--and, of
course, we do--then we should be looking at reducing this overhead of
communicating with the scheduler.  We should not be looking at the
different calling convention or the change of stacks, because those,
while not entirely free, are not the heaviest cost in the current
implementation.

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

[go-nuts] Re: encoding/html package to generate html markup programmatically

[Michael Ellis]

goht  might be what you're looking 
for.

On Sunday, March 14, 2021 at 7:36:52 PM UTC-4 atd...@gmail.com wrote:

> Hi,
>
> I am currently thinking about implementing SSR for a Go client-side 
> framework.
> Not only that but I would like to be able to create static html from the 
> same code I use to create dynamic  wasm-based webapps.
>
> I was trying to find a package that would enable me to generate an html 
> document but seems like none exists.
>
> Do you think it is possible to use encoding/xml to create an xhtml 
> document?
>
>
> That would allow me to create something like MarkupPy that would replace 
> js DOM created element by html element.
>
>

-- 
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/33063788-a96e-40f3-820a-78a34b7725f1n%40googlegroups.com.

[go-nuts] running tests against benchmarks

[Jeremy French]

I keep running into this solution to a particular problem, but when I go to 
search on how to do it, I find that not only are there seemingly no 
solutions out there in search-results-land, there doesn't seem to be anyone 
else even asking about it.  This then leads me to suspect, that I'm going 
about it in completely the wrong mindset, and I'd appreciate anyone helping 
me see how everyone else is solving this problem.

The issue is this:  Let's say I have some function - call it BeefyFunc() - 
that is heavily relied upon and executed many times per second in my 
high-traffic, high-availability critical application.  And let's say that 
BeefyFunc() is very complex in the sense that it calls many other functions 
which call other functions, etc, and these called functions are spread out 
all over the code base, and maintained by a broad and distributed 
development team (or even just one forgetful, overworked developer).  If 
BeefyFunc() currently executes at 80 ns/op on my development machine, I 
want to make sure that no one makes some change to an underlying function 
which causes BeefyFunc to balloon up to 800 ns/op.  And more to the point, 
if that ballooning does happen, I want someone to be notified, not to have 
to rely on a QA person's ability to notice a problem while scanning the 
benchmark reports.  I want that problem to be highlighted in the same way a 
test failure would be.

So it seems like the logical solution would be to create a test that runs a 
benchmark and makes sure the benchmark results are within some acceptable 
range.  I realize that benchmarks are going to differ from machine to 
machine, or based on CPU load, etc.  But it seems like it would still be 
useful in a CI/CD situation or on my personal dev machine, where the 
machine hardware is stable and known and the CPU load can be reasonably 
predicted, that at least a sufficiently wide range for benchmarks could be 
reasonably enforced and tested for.

Am I being stupid? Or is this a solved problem and it's just my google-fu 
that's failing me?

-- 
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/7adf598e-03a8-456a-a52f-824a8d1832e3n%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 

Re: [go-nuts] Why do type aliases change behaviour (i.e. json.Unmarshal)?

[cpu...@gmail.com]

Thank you @Michel. Disturbing that I keep making the same mistake again...

On Monday, March 15, 2021 at 2:05:53 PM UTC+1 mlevi...@gmail.com wrote:

> This is because per the Go spec: 
> https://golang.org/ref/spec#Type_declarations
> You're not creating an alias to Token, but defining a new type from it. If 
> what you are looking for is an alias (meaning to have the "WrappedToken" 
> identifier refer to the exact same type as Token), you need to do:
>
> type WrappedToken = Token
>
> Then all method calls on WrappedToken will be method calls on Token (since 
> both identifier denote the same type).
>
> But maybe that is not what you are looking for, if that's the case, there 
> are other ways around the problem, like type embedding and such.
> Hope this helps,
>
> Le lun. 15 mars 2021 à 13:49, cpu...@gmail.com  a 
> écrit :
>
>> I've just tried doing something like this in my code:
>>
>> // Token is an OAuth2 token which includes decoding the expires_in 
>> attribute
>> type Token struct {
>> oauth2.Token
>> ExpiresIn int `json:"expires_in"` // expiration time in seconds
>> }
>>
>> func (t *Token) UnmarshalJSON(data []byte) error {
>> ...
>> }
>>
>> type WrappedToken Token
>>
>> Only to find out, that unmarshaling a WrappedToken does not call 
>> Token.UnmarshalJSON which came as a bit of surprise.
>>
>> I can only guess it's due to how JSON unmarshaling works, but is this the 
>> intended behaviour?
>>
>> Kind regards,
>> Andreas
>>
>> -- 
>> 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/0ceb1917-af61-4259-8695-55eeb0bd6bffn%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/77f8d500-4f9d-4558-8be5-658230cbb18an%40googlegroups.com.

[go-nuts] Re: [ANN] New german translations

[Haddock]

I agree that Quellcode or Quelltext are the best transalations IMHO other 
than just using Code

HaWe schrieb am Sonntag, 14. März 2021 um 09:11:14 UTC+1:

> Hello Tim.
>
> Translating, that's a hobbyhorse I ride now and then.
> (Learn something new about Go and improve your English and German in 
> parallel! ;-)
>
> No, sorry. There is no public repository. The private one right here under 
> my desk is ... well ... private.
>
> Now, about you taking up translating: that's a great idea. Many of the Go 
> documents could be worth the effort; the blog posts about modules come to 
> mind. (Write to me off-list if I can be of any help; email address is in 
> the top box of any of the translations.)
>
> (BTW there had been a german version of the Tour of Go from 2015 by one 
> Michael Faschinger, but alas, that seems to be no longer accessible.)
>
> I'm still thinking about rufen vs. aufrufen; since it's not only about 
> calling functions but about exported types and variables as well, the 
> appropriate word could be "benutzen". (Changes will be in the next release; 
> following Go 1.17.)
>
> So long
> HaWe
>
> a2800276 schrieb am Freitag, 12. März 2021 um 15:14:38 UTC+1:
>
>> "Kode" really seems nonstandard to me. It really pops out. I'd definitely 
>> spell it "Code" in German and even then it seems like colloquial usage. I'd 
>> prefer Quellcode or Quelltext or Programm. 
>> "Kode aus einem externen Paket rufen" should really be "aufrufen" no 
>> matter how you feel about "Kode" :)
>>
>> Are you looking for help with the translations? I'd be happy to work with 
>> you on them for a while. Is there a repo anywhere?
>>  -tim
>>
>> On Thursday, 11 March 2021 at 20:53:43 UTC+1 HaWe wrote:
>>
>>> Thanks for your comments. It's nice when one's work is appreciated.
>>> About choice of words, have a look at the "Wörterliste". The link is in 
>>> the box at the top.
>>> About Spelling: that seems to be a question of age. I learnt the word 
>>> "Kode" long before I came across computers (but I do use "Computer" in 
>>> german sometimes).
>>>
>>> Uli Kunitz schrieb am Mittwoch, 10. März 2021 um 21:53:04 UTC+1:
>>>
 The authority on German Orthography, duden.de, recommends the writing 
 Code but allows Kode as well.

 On Wednesday, March 10, 2021 at 7:34:05 PM UTC+1 Haddock wrote:

> I don't know about using the word "Kode" in German. I've never seen it 
> different than with c as in English. Whatever, you took a big effort and 
> did a very nice job. Thank you!
>
> HaWe schrieb am Dienstag, 9. März 2021 um 17:26:48 UTC+1:
>
>> Just finished german translation of the two new tutorials:
>>
>> https://bitloeffel.de/DOC/golang/getting-started_de.html 
>> https://bitloeffel.de/DOC/golang/create-module_de.html
>>
>> Maybe that helps some newcomers.
>>
>> In the menu you'll find all the other Go documents I translated over 
>> the years. I tried to keep them up-to-date.
>>
>

-- 
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/26d1ec47-e23e-4bee-a859-dd041cd23688n%40googlegroups.com.

Re: [go-nuts] Auto Make a named return map

['Axel Wagner' via golang-nuts]

On Mon, Mar 15, 2021 at 2:19 PM Kevin Chadwick  wrote:

> Whilst you have wrongly called some things in this thread irrelevant.
>

To be clear: I meant they are not relevant to the discussion of the
property that a zero value is represented by 0 bytes.
I explained why (they are questions about the semantics of using maps,
whereas the memory representation is an implementation detail) and I stand
by that.

That is irrelevant to this discussion as the reasons that Python is slower
> have
> very little to do with this discussion.


Certainly, if "C gives up too much convenience for the sake of performance"
is pertinent to the discussion, then so is "Python gives up too much
performance for the sake of convenience"? I would tend to agree that
*neither* is particularly relevant (as comparing languages is relatively
futile) but saying one is and one isn't seems an arbitrary double-standard
to me.

To repeat, I didn't really try to make a case one way or another. I agree
that it would be nice to not have nil-maps in the language. I also agree
that we should not ignore the performance impact of that. I'm just trying
to explain why things are the way they are.

Whilst issues like this and ones already
> fixed by go, do pertain to c.
>
> I shall see if the staticcheck SA5000 linter can be improved to track
> returns or
> submit a proposal at some point or wait for null safety to fix this issue.
>
> --
> 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/3f7e04d7-b18d-6d05-8d7f-eaa04b79c368%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/CAEkBMfEs%2B%3DUJ5GXb1_pegCN6%3DGe3y_eEv%2BnYgb_Ox5pB-2kzcA%40mail.gmail.com.

Re: [go-nuts] Auto Make a named return map

[Kevin Chadwick]

On 3/13/21 5:27 PM, 'Axel Wagner' via golang-nuts wrote:

>  
> I'm once again not sure what your objective is here. No one is trying to argue
> that it is impossible to introduce semantics like you propose.
> We are only trying to give you the reasons why that's currently not done.
> 
> You can always file a proposal to change the semantics. But I would strongly
> suggest to a) get acquainted with the reasons given to you for why maps work 
> the
> way they do and b) have good answers ready when they come up in the 
> discussion.
> At least better answers than just dismissing them. If your only response to
> someone saying that performance would suffer to much if we had to allocate a 
> map
> for every zero value is "that is performance nonsense", my prediction is that
> your proposal would not get very accepted.

That was not my answer or "only response"!

>> If you are doing something a billion times then whatever you are doing is
>> more expensive than allocating a zero map. You can also avoid that return if
>> really necessary, which I doubt. It is right for optimisation steps to
>> increase, over run of the mill stuff.

e.g. append vs array

>> Nonsense around performance is the reason that c sucks.

perhaps I should have said, nonsense by default, but it is inferred from context


> Lack of "nonsense around performance" is also the reason why many people use
> Go instead of, say, Python.

Whilst you have wrongly called some things in this thread irrelevant.
That is irrelevant to this discussion as the reasons that Python is slower have
very little to do with this discussion. Whilst issues like this and ones already
fixed by go, do pertain to c.

I shall see if the staticcheck SA5000 linter can be improved to track returns or
submit a proposal at some point or wait for null safety to fix this issue.

-- 
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/3f7e04d7-b18d-6d05-8d7f-eaa04b79c368%40gmail.com.

Re: [go-nuts] Why do type aliases change behaviour (i.e. json.Unmarshal)?

[Jan Mercl]

On Mon, Mar 15, 2021 at 1:49 PM cpu...@gmail.com  wrote:

> type WrappedToken Token

Note that this is not a type alias. WrappedToken is a new type. Even
if its underlying type is Token, WrappedToken does not automatically
have any methods of Token.

> Only to find out, that unmarshaling a WrappedToken does not call 
> Token.UnmarshalJSON which came as a bit of surprise.

To be less surprised, check the language specs that say this is how
the type system works.

-- 
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/CAA40n-XRj3sRkZdEoAPVu4VnLnSvtEzvV8hiUUvOpoUjFzPuEw%40mail.gmail.com.

Re: [go-nuts] Why do type aliases change behaviour (i.e. json.Unmarshal)?

[Levieux Michel]

This is because per the Go spec:
https://golang.org/ref/spec#Type_declarations
You're not creating an alias to Token, but defining a new type from it. If
what you are looking for is an alias (meaning to have the "WrappedToken"
identifier refer to the exact same type as Token), you need to do:

type WrappedToken = Token

Then all method calls on WrappedToken will be method calls on Token (since
both identifier denote the same type).

But maybe that is not what you are looking for, if that's the case, there
are other ways around the problem, like type embedding and such.
Hope this helps,

Le lun. 15 mars 2021 à 13:49, cpu...@gmail.com  a écrit :

> I've just tried doing something like this in my code:
>
> // Token is an OAuth2 token which includes decoding the expires_in
> attribute
> type Token struct {
> oauth2.Token
> ExpiresIn int `json:"expires_in"` // expiration time in seconds
> }
>
> func (t *Token) UnmarshalJSON(data []byte) error {
> ...
> }
>
> type WrappedToken Token
>
> Only to find out, that unmarshaling a WrappedToken does not call
> Token.UnmarshalJSON which came as a bit of surprise.
>
> I can only guess it's due to how JSON unmarshaling works, but is this the
> intended behaviour?
>
> Kind regards,
> Andreas
>
> --
> 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/0ceb1917-af61-4259-8695-55eeb0bd6bffn%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/CAL4P9zzd8YpC7QuFO6wBxxHxmeNGQtxYmATVscKs2m3_tfMvZw%40mail.gmail.com.

[go-nuts] Why do type aliases change behaviour (i.e. json.Unmarshal)?

[cpu...@gmail.com]

I've just tried doing something like this in my code:

// Token is an OAuth2 token which includes decoding the expires_in attribute
type Token struct {
oauth2.Token
ExpiresIn int `json:"expires_in"` // expiration time in seconds
}

func (t *Token) UnmarshalJSON(data []byte) error {
...
}

type WrappedToken Token

Only to find out, that unmarshaling a WrappedToken does not call 
Token.UnmarshalJSON which came as a bit of surprise.

I can only guess it's due to how JSON unmarshaling works, but is this the 
intended behaviour?

Kind regards,
Andreas

-- 
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/0ceb1917-af61-4259-8695-55eeb0bd6bffn%40googlegroups.com.

[go-nuts] %v for []string{} and []string{""}

[Brian Candler]

I was slightly surprised to discover that the Print() output for an empty 
slice, and a 1-element slice containing the empty string, are the same:

https://play.golang.org/p/btkzgk4LMT9

It does follow logically from the rules 
.  I guess I need to train myself 
to use %q or %#v.

-- 
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/59ccdf74-a80d-43a1-84e3-3fbef57ac571n%40googlegroups.com.

Re: [go-nuts] No generic, part -2

[Space A.]

Entropy tends to grow. Good things tend to become less good and even bad
over time. This is how the Universe works. Does C++ become a better
language by adding more and more features? What about Java? What makes you
think that people who were behind other languages weren't doing the same as
what "Go team" now trying to do? What's the difference? I really loved Java
at the beginning.


пн, 15 мар. 2021 г. в 03:24, David Skinner :

> I considered generics so important to our workflow that I added it quite
> some time ago, Go is an implementation language, you may implement anything
> you like with it. If you do not like the way it does something, you can use
> it to create a different language, that is what real programmers do. And Go
> makes it very easy to do. When I first started, I was writing machine code
> in octal and years later could read hex dumps the way others could ASM. The
> real problem is that each person who implemented a generics solution did so
> lightly differently so the learning curve is steep and the talent pool is
> shallow. Having well-defined generics for everyone to use will greatly
> benefit the 10% who rolled their own solution and make it easier for
> newbies who must later maintain that code. Heaven helps those who have to
> read my obscure proprietary generics code.
>
> The real problem is to be able to create useful abstractions. Packages
> should be orthogonal APIs, functions should be descriptive, RPCs should not
> have a plethora of microservices for no good reason. Modules and Generics
> are really great and wonderful and save time, but only if used wisely and
> correctly and only as needed. Modules introduced chaos, the dust will
> settle. Generics shall also introduce chaos, but then those who learn to
> use it wisely and effectively shall enjoy and productivity improvement, and
> then that dust will settle.
>
> I have personal reasons to have great trust in the Go team. Go has solved
> a plethora of problems for me already.
>
> On Saturday, March 13, 2021 at 11:35:23 AM UTC-6 axel.wa...@googlemail.com
> wrote:
>
>> On Sat, Mar 13, 2021 at 6:24 PM Space A.  wrote:
>>
>>> There is a huge difference between generics and some regular questions
>>> like `Etag` implementation, isn't it? In time, investments, "community
>>> demand", commitments to upper management, etc
>>>
>>
>> Indeed. That doesn't change the fact that Russ has a track record and I
>> trust him.
>>
>>
>>> And Russ didn't write academic paper regarding it
>>>
>>
>> Apparently I missed something. I'm unaware of any papers by Russ.
>>
>>
>>> (before accepting proposal in less than a month after it was published).
>>> =)
>>>
>>
>> The proposal has been evolving and discussed for almost three years
>> before that. The reason it got accepted in the space of a months is that it
>> was only published as a proposal once the authors felt confident that the
>> refinements they made in response to the public discussion were sufficient
>> to make it acceptable. In particular, it has changed very little from the
>> version they posted more than a year earlier. After three years of
>> discussion, it would have been surprising if new flaws would have surfaced
>> that made it intractable.
>>
>> It is a testament to how thoroughly it was discussed, not an indication
>> that it wasn't.
>>
>> FWIW, if you only focus on the one-month period between the proposal
>> getting posted and it being accepted, I am beginning to understand why you
>> think there was never a possibility of it being rejected. It would mean you
>> are unaware of the decade of discussion preceding it.
>>
>>
>>
>>> сб, 13 мар. 2021 г. в 19:39, Axel Wagner :
>>>
 On Sat, Mar 13, 2021 at 4:59 PM Space A.  wrote:

> You are a smart guy, one of the smartest I have ever talked to. But it
> looks like you somehow missed a very obvious thing. The people you
> mentioned (and most of the so-called Go team) AFAIK are Google employees.
> They work for a company and they are paid for the work they do.
>

 I did not miss this.


> If, as you say, they spend so much time, literally years, keep
> replying "if we find an approach that gives value blablabla", how do you
> imagine anyone responsible for the process at the end say smth like:
> "Alright guys, after spending so many man-years we have few solutions, but
> we finally realized that we were moving in wrong direction, so now we 
> gonna
> be dropping everything for the sake of better future of Go".
>

 The person responsible for the process (if there is any one person) is
 Russ. I would have expect him to say that, if it was his opinion. He has a
 good track record of acknowledging the arguments on all sides of the
 process and committing to a decision - even it if goes contrary to a
 previous statement of his.

 Here is a recent example I was involved in
 

Re: [go-nuts] No generic, part -2

[Space A.]

 > For example, the multiple proposals that flowed out of
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
.
None of them have been adopted.

I remember what was happening to "try" error handling proposal. It was
withdrawn only because of active resistance by the community.

And what's happened to a new "generics" proposal, it also got a lot of
critics but was "accepted" in less than a month after formal publication on
github. As Russ said "No change in consensus". What does it mean? Who are
these people who can change the consensus? How was it measured? A few days
after Russ locked it, so nobody can even say a word against it if they
wanted. So it looks very much that company management learned from "try"
proposal.



пн, 15 мар. 2021 г. в 05:27, Ian Lance Taylor :

> On Sat, Mar 13, 2021 at 7:59 AM Space A.  wrote:
> >
> > You are a smart guy, one of the smartest I have ever talked to. But it
> looks like you somehow missed a very obvious thing. The people you
> mentioned (and most of the so-called Go team) AFAIK are Google employees.
> They work for a company and they are paid for the work they do. If, as you
> say, they spend so much time, literally years, keep replying "if we find an
> approach that gives value blablabla", how do you imagine anyone responsible
> for the process at the end say smth like: "Alright guys, after spending so
> many man-years we have few solutions, but we finally realized that we were
> moving in wrong direction, so now we gonna be dropping everything for the
> sake of better future of Go". Like c'mon? Read what's written, not just
> words and punctuation, it was a one way ticket (and managers knew it), if
> you start this process, start spending money and reporting man hours, you
> know that it will land somewhere.
>
> I understand that argument, but I don't believe that it accurately
> describes the development of the language.  The clearest way to see
> that is by looking at counter-examples.  There have been several
> efforts to change the Go language in the past that have, to date,
> failed to occur, despite people "spending money and reporting man
> hours."  For example, the multiple proposals that flowed out of
>
> https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
> .
> None of them have been adopted.
>
> The people who work on Go, including the managers, are aware of the
> risks of "we've started this project so we must complete it."
> Language development doesn't work that way.  It's OK to realize that
> some ideas just can't be made to work.
>
> This is helped by the fact that most language changes don't require
> much work to start out.  For many years I was the only person working
> on generics in Go, and I certainly wasn't doing it full time.  Then
> for several years it was Robert Griesemer and I, again not full time.
> Today there are several people working on generics in Go, but that is
> only because we got it to the point of a proposal that could be
> accepted.
>
>
> > And I repeat, there wasn't a (public) question or discussion or anything
> regarding should we drop this topic entirely.
>
> There have been many public discussions on this mailing list as to
> whether generics should be dropped entirely.
>
> 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/CADKwOTcsNzf-jT2gC331kmd0E99dKZm77t3djjqDoHsFrnwVLQ%40mail.gmail.com.

Re: [go-nuts] No generic, part -2

[Space A.]

Sorry, of course it's Robert, my mistake.

пн, 15 мар. 2021 г. в 05:30, Ian Lance Taylor :

> On Sat, Mar 13, 2021 at 9:25 AM Space A.  wrote:
> >
> > And Russ didn't write academic paper regarding it (before accepting
> proposal in less than a month after it was published). =)
>
> There may be some confusion here.  Are you referring to the
> Featherweight Go paper (https://arxiv.org/abs/2005.11710)?  Russ
> wasn't involved with that.  And it was written in early 2020, long
> before the generics proposal was accepted.
>
> Or is there some other paper that I am not aware of?
>
> 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/CADKwOTcwcsmfWvKio-%2BQKZUN8bsK157aADKm0qcukbh5WNVh5A%40mail.gmail.com.

Re: [go-nuts] Analysis check for leaked pointers to loop variable address

[Barisere Jonathan]

That's correct. I've found that it's most often a mistake when working with 
slices. But for maps, there is some use for it, such as relying on maps 
being unordered to select random values from the map, although there should 
be a better way to do that.
An analysis check for this should produce a warning. I'm betting that since 
it's an error in most of the cases I've come across, a warning will be 
useful most of the time.

On Monday, March 15, 2021 at 8:34:14 AM UTC+1 Jan Mercl wrote:

> On Mon, Mar 15, 2021 at 3:03 AM Barisere Jonathan 
>  wrote: 
>
> > I think this mistake can be caught by code analysis tools, but I don't 
> know of any that catches these. 
>
> IMO the problem is that while sometimes it's a mistake, in some other 
> cases it is not and it is perfectly good, reasonable code. Next to 
> impossible for a machine to decide which case it sees. 
>

-- 
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/dffb2987-2c48-4d21-af0d-18a44ac343f9n%40googlegroups.com.

[go-nuts] Re: yet another code gen: specialized datastructure

[Michał Matczuk]

I invite you to take a look at [1] a bazel-free version of Google 
go_generics tool 
 released 
with gVisor project. It is used to make [2].

[1] https://github.com/mmatczuk/go_generics 
[2] https://github.com/scylladb/go-set

niedziela, 14 marca 2021 o 13:50:37 UTC+1 clement...@gmail.com napisał(a):

> hi,
>
> I recently wanted to get the juice out of some programs. 
> A queue consumer that transforms inputs over many routines,
> then aggregates the results to re order them.
> The order is defined by the input order.  
>
> There was many variations written around it,
> using a map, a slice, a regular heap, and finally,
> a specialized heap (hand written).
>
> Slice was best for its simplicity, regular heap made 
> with the package `container/heap` was not as good as expected.
> The specialized heap was the best for performance,
> but having this added complexity for only one small
> library of ~100LOC did not seem a good idea.
>
> So I wrote a template, included and rewrote the tests from
> `container/heap`, et voilà, it makes sense. 
> It is tested, re usable, and made for perf.
>
> The template are available at 
> https://github.com/clementauger/jenjen-datastructure
>
> Then you run (or add it via //go:gen..) 
> jenjen -template=github.com/clementauger/jenjen-datastructure/heap \ 
> - "U => -, T => -, Heap=>MinIntHeap , MinIntHeap:U=>int, MinIntHeap:T=> 
> minInt"
>
> It generates for you a Heap that takes in input regular ints, output 
> regular ints, but internally stores them as minInt.
> See 
> https://github.com/clementauger/jenjen-datastructure/blob/main/examples/heap/jenjen_heap.go#L38
>
> So does it do any good ? 
>
> $ (cd examples/heap; go test -bench=. -benchmem -count=2)
> goos: linux
> goarch: amd64
> pkg: github.com/clementauger/jenjen-datastructure/examples/heap
> BenchmarkMinIntHeap-49439108133 ns/op   8 
> B/op   0 allocs/op
> BenchmarkMinIntHeap-4   1107884 ns/op   8 
> B/op   0 allocs/op
> BenchmarkRegularHeap-4   3523325731 ns/op  23 
> B/op   0 allocs/op
> BenchmarkRegularHeap-4   3433321977 ns/op  23 
> B/op   0 allocs/op
> PASS
> ok  github.com/clementauger/jenjen-datastructure/examples/heap   
>  4.452s
>
> (I hope i have not made a mistake writing the comparison benchmarks, i 
> would not like to criticize the core language implementation in such 
> fashion...)
>
> Notes: 
> 1/ I have to say i was surprised to not find an existing similar project 
> using genny  (a more popular code 
> generator), did i miss something ?
>
> Clément
>

-- 
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/3b6061b1-1240-4edc-9d62-8c8e826c24f4n%40googlegroups.com.

Re: [go-nuts] Analysis check for leaked pointers to loop variable address

[Jan Mercl]

On Mon, Mar 15, 2021 at 3:03 AM Barisere Jonathan
 wrote:

> I think this mistake can be caught by code analysis tools, but I don't know 
> of any that catches these.

IMO the problem is that while sometimes it's a mistake, in some other
cases it is not and it is perfectly good, reasonable code. Next to
impossible for a machine to decide which case it sees.

-- 
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/CAA40n-WFjrjgaOF_0-HgxXj2dRMaMsJ7Yg%2BNEtq41JCHFxifLA%40mail.gmail.com.