Re: [go-nuts] Re: About the Google logo on the new Go website
what you're doing has a term: character assassination. please take it elsewhere. there are plenty of forums to air your grievances. On Thu, Jul 18, 2019 at 11:31 PM Space A. wrote: > > Another funny thing and I'm glad that you mentioned, is that "Woman Who Go" > and other known "non-google" initiatives, as you said, were founded or > co-founded by "developer advocate" Ashley McNamara. I don't know what kind of > contract or collaboration, or relations she had with Google or Google > employees, but she was quite "official" I would say, on all these > conferences. Now, she works for Microsoft. She also created and promoted own > printshop with Go-related merch with help of official Go community channels: > conferences, social networks, slack, etc. So, the interesting thing is that > in the post in Go blog it was claimed that 100% of money from new "official" > store will go to so-called non-profit org "GoBridge": > https://github.com/gobridge/about-us > which is also seems to be founded or co-founded by her, along with other > existing Google and (perhaps some of the) ex-Google employees: > https://github.com/gobridge/about-us#leadership-team > Ashley McNamara name there on the first place. > > You can Google a lot with her name and "GoBridge", "Woman Who Go" and other > keywords. For example here is her Patreon where she collects donations for > Go-related artworks, and also mentions that "Woman Who Go" and "GoBridge" are > being merged: https://www.patreon.com/posts/women-who-go-24864094 > > So all money will still go to that same project but now with promotion made > on very top level, in official Go Programming Language blog. Even if that org > is true and registered "non-profit" org, I suspect it still pays salaries and > give contracts to sub-contractors. I tried to find any financial reports and > proofs or evidence of real actions taken, but all I found is some very > general stuff. At least it very suspicious. I don't believe that Google can't > fund such a non-profit initiative without affecting true artists. > > And apparently, very unlikely, that you paid a cent to any independent artist > over that years. > > > > On Friday, July 19, 2019 at 6:13:26 AM UTC+3, andrey mirtchovski wrote: >> >> really? throughout the years (and I've been here since the beginning) >> i have spent infinitely more on non-google "go" merch than on google >> go merch: stickers, t-shirts, campaigns supporting women who code, >> etc, etc. >> >> come on. get off your high horse. > > -- > 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/39fb6e76-6acb-4470-b249-bcb202580d45%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/CAK4xykXes7KZfC939kzUkTrZivhqXhV3fv9PP4bHoSM-1EqM4A%40mail.gmail.com.
Re: [go-nuts] Re: About the Google logo on the new Go website
Another funny thing and I'm glad that you mentioned, is that "Woman Who Go" and other known "non-google" initiatives, as you said, were founded or co-founded by "developer advocate" Ashley McNamara. I don't know what kind of contract or collaboration, or relations she had with Google or Google employees, but she was quite "official" I would say, on all these conferences. Now, she works for Microsoft. She also created and promoted own printshop with Go-related merch with help of official Go community channels: conferences, social networks, slack, etc. So, the interesting thing is that in the post in Go blog it was claimed that 100% of money from new "official" store will go to so-called non-profit org "GoBridge": https://github.com/gobridge/about-us which is also seems to be founded or co-founded by her, along with other existing Google and (perhaps some of the) ex-Google employees: https://github.com/gobridge/about-us#leadership-team Ashley McNamara name there on the first place. You can Google a lot with her name and "GoBridge", "Woman Who Go" and other keywords. For example here is her Patreon where she collects donations for Go-related artworks, and also mentions that "Woman Who Go" and "GoBridge" are being merged: https://www.patreon.com/posts/women-who-go-24864094 So all money will still go to that same project but now with promotion made on very top level, in official Go Programming Language blog. Even if that org is true and registered "non-profit" org, I suspect it still pays salaries and give contracts to sub-contractors. I tried to find any financial reports and proofs or evidence of real actions taken, but all I found is some very general stuff. At least it very suspicious. I don't believe that Google can't fund such a non-profit initiative without affecting true artists. And apparently, very unlikely, that you paid a cent to any independent artist over that years. On Friday, July 19, 2019 at 6:13:26 AM UTC+3, andrey mirtchovski wrote: > really? throughout the years (and I've been here since the beginning) > i have spent infinitely more on non-google "go" merch than on google > go merch: stickers, t-shirts, campaigns supporting women who code, > etc, etc. > > come on. get off your high horse. > -- 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/39fb6e76-6acb-4470-b249-bcb202580d45%40googlegroups.com.
Re: [go-nuts] Does reducing capacity of a slice return memory?
Thank you Ian, you reply is very much appreciated. ... what if a compiler would do a bit of helping "magic"? I would suspect it does know that you return a subslice of an allocated array (something that compiler still sees up the call stack). Would it be possible to put a code for "This big alloc is going out of scope. If resulting (surviving) slice is less than a X% of that original thing, copy needed part, and point a new slice there". Simple cases only - ints, strings, bytes. Struct of anything with pointers are no-go (pardon the pun) - they might point to another item in the same array. For cases of huge allocs, running-close-to-mem-limits, X will have to be smaller, so you would not OOM right there. Unless I miss something big and obvious - which is very highly possible - that sounds like a possible way to drop wasted space, keeping small part required on a side. Again, thank you very much for the answer. Andrey On Thursday, July 18, 2019 at 10:57:26 AM UTC-6, Ian Lance Taylor wrote: > > On Thu, Jul 18, 2019 at 8:35 AM Andrey Tcherepanov > > wrote: > > > > > Basically, it's hard to be sure that there isn't any other slice > somewhere that might permit references to that trailing memory > > > > Ian, I am kind of curious about this case. I understand that "hard" is > not "impossible", but still - if I copy the needed part to a smaller array, > how does the GC knows that there are no more slices pointing to a part of > an old allocation? > > I'm not sure precisely what you are asking. Conceptually, the GC > starts with global variables and goroutine stacks and traces all > pointers to find all reachable memory. Unreachable memory is > discarded. > > What makes this case harder is that we need to not only track > pointers, we need to also look at the slice information to turn the > pointer to the backing array into a sort of bounded pointer: a pointer > to only part of the object, not all of it. That means that the GC has > to understand slice structures, which are more complex than pointers. > It means that the compiler has to build slice structures in a way that > the GC can understand, which it currently does not do. That may sound > simple, but currently the compiler splits up local slices into three > independent local variables, and that would either become impossible > or would require significantly more data to be recorded for the GC. > > Another wrinkle is that the current memory allocator does not support > shrinking memory allocations at all, since that currently never > happens. The allocator is based on storing objects of the same size > together, so it's not easy to split an existing object into smaller > sizes. That said, very large objects do have to be handled > differently and it might be more feasible to shrink those objects; I'm > not sure. > > So those are some of the reasons why it is hard. > > 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/6160bc33-1ec0-4c17-ae50-e817e822fd3a%40googlegroups.com.
[go-nuts] Re: Do Any Editors Support Customisable Code collapsing?
I don't know how this works for vscode, but for GoLand you can write your own syntax-aware custom folding plugin, see this plugin as an example of how to do it: https://plugins.jetbrains.com/plugin/9320-advanced-java-folding This doesn't mean we are not open to new ideas on how to improve the error handling display to all users by default and we are happy to listen on your opinions/needs. On Friday, July 19, 2019 at 5:58:19 AM UTC+3, kez@gmail.com wrote: > > Thanks! I haven't heard of GoLand before. > > Looks like the One Line Returns feature is like an 80% solution, I would > toggle that on all the time. > > I'm not sold on completely hiding the error line like you want, but I'll > definitely start a thread with that GoLand dev about how hard it would be > to make the folding slightly more generic. > > On Friday, 19 July 2019 10:18:52 UTC+10, Mike Schinkel wrote: >> >> Are there any editors that support some kind of customisable collapsing >>> behaviour? Where the above code could be collapsed to something like: >>> >> >> Might be worth reading, commenting on and/or possibly upvoting this >> feature proposal for GoLand? >> >> https://youtrack.jetbrains.com/issue/GO-7747 >> > -- 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/9d86c422-a591-48ca-8f22-0b38e67bc36c%40googlegroups.com.
Re: [go-nuts] Re: About the Google logo on the new Go website
> Funny thing that today Google has announced "official" store for Go-related > merch, which in it's essence is a try to take away even an even tiny business > opportunities for artists who were creating some goods and had a very very > little outcome on this. Now they will have ZERO. really? throughout the years (and I've been here since the beginning) i have spent infinitely more on non-google "go" merch than on google go merch: stickers, t-shirts, campaigns supporting women who code, etc, etc. come on. get off your high horse. -- 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/CAK4xykW0pyNLUXb2w8Bb8OP_FcMex09WOnH7YtUTPiag3EDu4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Do Any Editors Support Customisable Code collapsing?
Thanks! I haven't heard of GoLand before. Looks like the One Line Returns feature is like an 80% solution, I would toggle that on all the time. I'm not sold on completely hiding the error line like you want, but I'll definitely start a thread with that GoLand dev about how hard it would be to make the folding slightly more generic. On Friday, 19 July 2019 10:18:52 UTC+10, Mike Schinkel wrote: > > Are there any editors that support some kind of customisable collapsing >> behaviour? Where the above code could be collapsed to something like: >> > > Might be worth reading, commenting on and/or possibly upvoting this > feature proposal for GoLand? > > https://youtrack.jetbrains.com/issue/GO-7747 > -- 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/e8943581-72ed-4f15-afc5-2bb0b0b057cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: About the Google logo on the new Go website
Funny thing that today Google has announced "official" store for Go-related merch, which in it's essence is a try to take away even an even tiny business opportunities for artists who were creating some goods and had a very very little outcome on this. Now they will have ZERO. Well done Google. > Open source programmers have families that need food and housing, they need companies that are willing to compensate them for their work. We need to give thanks for those who support the language, not just Google, but everyone. -- 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/CADKwOTebUiRHxz3vc-Z%2BPfiv1AGUi28E2nmTe1iM4F784_QVWw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Build kubernetes with gollvm
Thank you. The explanation really makes sense. I think I should modify the source code of etcd, or change to another project that is not so hackful. On Thursday, July 18, 2019 at 10:55:39 PM UTC+8, Ian Lance Taylor wrote: > > On Thu, Jul 18, 2019 at 6:50 AM Yuan Ting > > wrote: > > > > Thank you for your fix. I have some curious about the difference between > the main Go compiler and gollvm. I read gollvm's readme and know that the > main difference comes from the efficiency of GC. Is the other difference > causes the symbol undefined reference as you mentioned above? Or some bugs > (or library version skew) that will be fixed in the future. > > The gc toolchain has a different assembler that does not use the same > syntax as standard assembler for a platform > (https://golang.org/cmd/asm). GoLLVM uses the standard assembler for > whatever platform it is being used on. So Go packages that use > assembler code, like golang.org/x/sys, have to use different code to > support gc and GoLLVM. That is part of your problem. (That code does > exist in current versions of golang.org/x/sys; the build above is > showing an older version of the package; it's quite possible that > current versions would work). > > The gc toolchain has a special approach for unifying type descriptors > that uses a runtime-specific symbol runtime.typelinks. GoLLVM does > not have that symbol. I don't know what github.com/modern-go/reflect2 > is, but it seems to be using unsafe mechanisms to reach into the > runtime to examine that symbol. That won't work with GoLLVM. The > reflect package in general is closely tied to the compiler, so it's > possible that whatever modern-go/reflect2 is, it will not work with > GoLLVM. > > 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/b8cdf106-750e-46c7-99c8-11999ee63d0d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: Do Any Editors Support Customisable Code collapsing?
> > Are there any editors that support some kind of customisable collapsing > behaviour? Where the above code could be collapsed to something like: > Might be worth reading, commenting on and/or possibly upvoting this feature proposal for GoLand? https://youtrack.jetbrains.com/issue/GO-7747 -- 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/eca35b41-df62-4c03-81b5-af55d113361a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Do Any Editors Support Customisable Code collapsing?
That's cool, having quick actions to do the folding is part way there.
Hehe, I am genuinely looking for a 'try' alternative! I think that an
editor-supported solution would keep everybody happy.
It would let the code be read as if it were written with some syntactic
sugar macro, but the code underneath is just plain golang code.
The Golang language/standard library doesn't have to support any macros,
which keeps the language team happy,
and since the code is unchanged, it lets each person decide which
collapsings they want to use (if any at all).
It looks like VSCode has a feature suggestion ticket in their backlog here:
https://github.com/microsoft/vscode/issues/70794
Which would at least make it possible for an extension to implement the
code folding I'm after.
I wonder if we can encourage VSCode to start working on it, or whether we
can get a group of Golang devs to work on it for them (it
is open source after all)...
On Friday, 19 July 2019 05:45:00 UTC+10, Michael Jones wrote:
>
> Ha!
>
> https://github.com/rstuven/vscode-iferrblocks
>
> On Thu, Jul 18, 2019 at 10:32 AM Jim Robinson > wrote:
>
>> Is it named try? :P
>>
>> On Wednesday, July 17, 2019 at 8:37:53 PM UTC-7, Michael Jones wrote:
>>>
>>> There is a special “collapse if err != nil blocks plugin for VS code.
>>>
>>> On Wed, Jul 17, 2019 at 5:37 PM wrote:
>>>
Context:
1. Golang can be very verbose, for example checking if err != nil after
a function call takes 3 lines:
if err != nil {
return nil, fmt.Errorf("some context: %v", err)
}
2. Editors like VSCode can already collapse blocks of statements, where
the above would be displayed as:
if err != nil {...
My question:
Are there any editors that support some kind of customisable collapsing
behaviour? Where the above code could be collapsed to something like:
...check...fmt.Errorf("some context: %v", err)...
Has anyone tried to implement this kind of behaviour? Is it difficult
to achieve?
--
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 golan...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e15556dd-b957-4d79-9ca4-8b6ed8eb6e6c%40googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.
>>> --
>>>
>>> *Michael T. jonesmichae...@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 golan...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/920a48e6-431d-40b2-8081-d0b207cb1840%40googlegroups.com
>>
>>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> *Michael T. jonesmichae...@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/1e0a1507-0eb4-48da-8ad1-54cace6a48d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is it a good idea to use atomic operations in setter and getter methods?
On Friday, July 19, 2019 at 1:01:27 AM UTC+8, Ian Lance Taylor wrote:
>
> On Thu, Jul 18, 2019 at 8:35 AM T L >
> wrote:
> >
> > For example:
> >
> > type Page struct {
> > views uint32
> > }
> >
> > func (page *Page) SetViews(n uint32) {
> > atomic.StoreUint32(, n)
> > }
> >
> > func (page *Page) Views() uint32 {
> > return atomic.LoadUint32()
> > }
> >
> > Keith Randall and Ian Lance Taylor said that atomic.Load is a
> memory_order_acquire
> > and atomic.Store is memory_order_release, so there is no memory order
> guarantees
> > between the following two calls, I think:
> >
> > atomic.StoreUint32(, n)
> > atomic.LoadUint32()
> >
> > In other words, the load result might not reflect the latest value of
> page.views.
>
> In these kinds of discussions it's hard to know what "latest value"
> means. But in general an atomic load will see any atomic store that
> preceded it in absolute time. The difference between load-acquire and
> sequentially-consistent-load is not with the atomic value itself; it's
> with all other memory accesses. The LoadUint32 will see the
> StoreUint32, but it may not see any other non-atomic memory stores
> done before the StoreUint32.
>
>
> > On the contrary, the memory order between the following two calls
> > is guaranteed to be as their order shown in code.
> >
> > atomic.LoadUint32()
> > atomic.StoreUint32(, n)
> >
> > Is my understanding right?
>
> So, per above, not quite.
>
> And that said, see the more recent discussion on
> https://golang.org/issue/5045, in which Russ argues that we should use
> sequential consistency anyhow.
>
> Ian
>
Thanks, Ian. I get it now.
--
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/f7039ec5-576a-4e8e-b347-9fdeb129a72f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] A unofficial Go error handling proposal
Inspired from reading
https://github.com/golang/go/issues/32437#issuecomment-50187
After some careful thoughts on various different concerns and criticisms of
the existing proposal, I'd want to give a try from a different approach.
Using the famous example of CopyFile:
func CopyFile(src, dst string) error {
r := os.Open!(src) || return
defer r.Close()
w := os.Create!(dst) || return fmt.Errorf("blah", capture())
io.Copy!(w, r) || return func() error {
w.Close()
os.Remove(dst)
return fmt.Errorf(..., capture())
}()
w.Close!()
}
Observations:
- Any functions that returns error can be called with "!" at the
function name, indicating the trigger of new error handling logic. There is
no need to change any function signature, this is recognized by compiler.
If a function doesn't return an error, adding "!" triggers a compilation
error.
- Introduce a new logic OR semantic. This should be very familiar among
most programmers (even if not, the implied meaning should be fairly
obvious).
- Introduce a built-in function called "capture()". It's simple, the
only thing it does is return the err captured from the most recent call.
- Calling an error function with "!" without handling code yields panic.
Line by line explanation:
- r := os.Open!(src) || return
if os.Open!(src) returns no error, r is assigned, otherwise, return is
executed. Noticed, there is no error handling code other than plainly
return the error. This is equivalent of
if r, err := os.Open(src); err != nil {
return err
}
Most GO programmers wrote code like this million times a day... :)
- w := os.Create!(dst) || return fmt.Errorf("blah", capture())
A bit more involved, doing some formatting of the err received and
return.
- io.Copy!(w, r) || return func() error {
w.Close()
os.Remove(dst)
return fmt.Errorf(..., capture())
}()
An even more involved error handling. Doing some cleanup, and
formatting, etc.
- w.Close!()
Nothing. If Close() failed with error, it panics!
Some rationales:
- There is no repetitive if/else error handling anymore. The assumption
is that the call site context should be rich enough for compiler to figure
out how to generate the right code and for the runtime to do the right
thing. e.g. "r := os.Open!(src) || return" The Go runtime should know that
if os.Open!(src) returns an error, "return" instructs to return that error
directly. If no, r gets assigned to the correct file object.
- The runtime should be able to trivially 'capture' the error returned
immediately from the caller. This is the idea borrowed from old C errno
semantic.
- There is no need to write two version of os.Open or whatnot, the "!"
version is recognized by compiler and automatically knows how to handle it.
Everyone writes the same function implementation as is.
- There is no implicit control flow redirects, no defer handling at the
last, no named parameters required, etc... For most Go programmers, they
_should_ feel that they are still writing normal Go code they familiar
with. This departs greatly from those exception-like syntax (try, check,
catch, handle, etc)
- Error handling is still on-spot, and should be very clear to readers.
- Error handling is still optional. e.g. you could also just write w :=
os.Create!(dst) || fmt.Print("do matter", capture()) which will continue
the program flow, or w := os.Create!(dst) with nothing to indicate a panic
intention. (Yes, someone wants an error to be fatal, but not everybody, so
let's provide a way for the ones want Fatal to fatal and ones don't want
fatal to error handling)
Thoughts? Bricks? Suggestions?
--
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/11336ba4-9d17-4bd4-ba3f-474732de7e75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Do Any Editors Support Customisable Code collapsing?
Ha!
https://github.com/rstuven/vscode-iferrblocks
On Thu, Jul 18, 2019 at 10:32 AM Jim Robinson
wrote:
> Is it named try? :P
>
> On Wednesday, July 17, 2019 at 8:37:53 PM UTC-7, Michael Jones wrote:
>>
>> There is a special “collapse if err != nil blocks plugin for VS code.
>>
>> On Wed, Jul 17, 2019 at 5:37 PM wrote:
>>
>>> Context:
>>> 1. Golang can be very verbose, for example checking if err != nil after
>>> a function call takes 3 lines:
>>> if err != nil {
>>>return nil, fmt.Errorf("some context: %v", err)
>>> }
>>>
>>>
>>> 2. Editors like VSCode can already collapse blocks of statements, where
>>> the above would be displayed as:
>>> if err != nil {...
>>>
>>>
>>> My question:
>>> Are there any editors that support some kind of customisable collapsing
>>> behaviour? Where the above code could be collapsed to something like:
>>> ...check...fmt.Errorf("some context: %v", err)...
>>>
>>> Has anyone tried to implement this kind of behaviour? Is it difficult to
>>> achieve?
>>>
>>>
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/e15556dd-b957-4d79-9ca4-8b6ed8eb6e6c%40googlegroups.com
>>>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> *Michael T. jonesmichae...@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/920a48e6-431d-40b2-8081-d0b207cb1840%40googlegroups.com
>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
*Michael T. jonesmichael.jo...@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/CALoEmQzhOPd5%2BpFMZYdwvhHuq4OudugZWnJE%2B0_1W5NgtSKt9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Re: About the Google logo on the new Go website
On Thu, Jul 18, 2019 at 11:21 AM David Skinner wrote: > > It is my opinion that it is only polite to acknowledge corporate sponsors in > a tangible way. > > The problem is if you have only one corporate sponsor. I know for a fact that > members of the Smythe Group have contributed time to Go dev without > compensation. Many other people have also made contributions of time while in > the employ of corporate sponsors. I would love to have Davsk acknowledged as > a contributor to Go but I am not that good of a programmer, I can write a few > articles, answer a few questions, write a few bug reports, teach a Go class > to CS students, and try very hard not to be a nuisance but that hardly > qualifies me to be acknowledged even with an 8x8 pixel icon. To be fair, > establish standards for display of corporate logo sponsorship, this will only > enhance the prestige of the language. > > A contribution of $1k is worth a 16x16 icon, > a $10k contribution is a full size logo, > Google contribution, maybe the logo should stretch from one side of the page > to the other. > > Open source programmers have families that need food and housing, they need > companies that are willing to compensate them for their work. We need to give > thanks for those who support the language, not just Google, but everyone. It's not at all the same as the web site, but I think it's worth noting that all contributors to the Go repository are acknowledged at https://golang.org/CONTRIBUTORS. That's not all contributors by any means. There are many people who help the Go project by answering questions, writing blog posts, running meetups, discussing issues and proposals, and in many other ways. It's hard to know how to acknowledge everybody who contributes. 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/CAOyqgcWbz92Tm220fo%2BPmCrsxy%2BM7QUQuJ4Sky%3D6MQVH52zCVg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Re: About the Google logo on the new Go website
It is my opinion that it is only polite to acknowledge corporate sponsors in a tangible way. The problem is if you have only one corporate sponsor. I know for a fact that members of the Smythe Group have contributed time to Go dev without compensation. Many other people have also made contributions of time while in the employ of corporate sponsors. I would love to have Davsk acknowledged as a contributor to Go but I am not that good of a programmer, I can write a few articles, answer a few questions, write a few bug reports, teach a Go class to CS students, and try very hard not to be a nuisance but that hardly qualifies me to be acknowledged even with an 8x8 pixel icon. To be fair, establish standards for display of corporate logo sponsorship, this will only enhance the prestige of the language. - A contribution of $1k is worth a 16x16 icon, - a $10k contribution is a full size logo, - Google contribution, maybe the logo should stretch from one side of the page to the other. Open source programmers have families that need food and housing, they need companies that are willing to compensate them for their work. We need to give thanks for those who support the language, not just Google, but everyone. On Monday, July 15, 2019 at 10:40:19 AM UTC-5, Michal Strba wrote: > > As you all know, the new, redesigned Go website has a Google logo in the > bottom right corner. > > Someone opened an issue about this, worrying that with the logo, nobody > will see Go as a community project: > https://github.com/golang/go/issues/33021 > > The issue was promptly closed and locked by a Go team member, which I must > admit, is kind of an unfair move. > > If you read this thread on r/programming, it seems like the worries are > quite justified: > https://www.reddit.com/r/programming/comments/ccidly/golang_issue_ticket_remove_the_google_logo/ > > I personally am fine with the logo. > > What do you think? For example, Rust has no Mozilla logo on its page > despite being largely funded by it. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b0688536-c336-4829-ab97-32fda2c800cc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Do Any Editors Support Customisable Code collapsing?
Is it named try? :P
On Wednesday, July 17, 2019 at 8:37:53 PM UTC-7, Michael Jones wrote:
>
> There is a special “collapse if err != nil blocks plugin for VS code.
>
> On Wed, Jul 17, 2019 at 5:37 PM > wrote:
>
>> Context:
>> 1. Golang can be very verbose, for example checking if err != nil after a
>> function call takes 3 lines:
>> if err != nil {
>>return nil, fmt.Errorf("some context: %v", err)
>> }
>>
>>
>> 2. Editors like VSCode can already collapse blocks of statements, where
>> the above would be displayed as:
>> if err != nil {...
>>
>>
>> My question:
>> Are there any editors that support some kind of customisable collapsing
>> behaviour? Where the above code could be collapsed to something like:
>> ...check...fmt.Errorf("some context: %v", err)...
>>
>> Has anyone tried to implement this kind of behaviour? Is it difficult to
>> achieve?
>>
>>
>>
>> --
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/e15556dd-b957-4d79-9ca4-8b6ed8eb6e6c%40googlegroups.com
>>
>>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
>
> *Michael T. jonesmichae...@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/920a48e6-431d-40b2-8081-d0b207cb1840%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Is it a good idea to use atomic operations in setter and getter methods?
On Thu, Jul 18, 2019 at 8:35 AM T L wrote:
>
> For example:
>
> type Page struct {
> views uint32
> }
>
> func (page *Page) SetViews(n uint32) {
> atomic.StoreUint32(, n)
> }
>
> func (page *Page) Views() uint32 {
> return atomic.LoadUint32()
> }
>
> Keith Randall and Ian Lance Taylor said that atomic.Load is a
> memory_order_acquire
> and atomic.Store is memory_order_release, so there is no memory order
> guarantees
> between the following two calls, I think:
>
> atomic.StoreUint32(, n)
> atomic.LoadUint32()
>
> In other words, the load result might not reflect the latest value of
> page.views.
In these kinds of discussions it's hard to know what "latest value"
means. But in general an atomic load will see any atomic store that
preceded it in absolute time. The difference between load-acquire and
sequentially-consistent-load is not with the atomic value itself; it's
with all other memory accesses. The LoadUint32 will see the
StoreUint32, but it may not see any other non-atomic memory stores
done before the StoreUint32.
> On the contrary, the memory order between the following two calls
> is guaranteed to be as their order shown in code.
>
> atomic.LoadUint32()
> atomic.StoreUint32(, n)
>
> Is my understanding right?
So, per above, not quite.
And that said, see the more recent discussion on
https://golang.org/issue/5045, in which Russ argues that we should use
sequential consistency anyhow.
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/CAOyqgcUz5vZeJj9jDk3YgU3kP0GmvY7nKkYqib4E-gcXGM1yjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Does reducing capacity of a slice return memory?
On Thu, Jul 18, 2019 at 8:35 AM Andrey Tcherepanov wrote: > > > Basically, it's hard to be sure that there isn't any other slice somewhere > > that might permit references to that trailing memory > > Ian, I am kind of curious about this case. I understand that "hard" is not > "impossible", but still - if I copy the needed part to a smaller array, how > does the GC knows that there are no more slices pointing to a part of an old > allocation? I'm not sure precisely what you are asking. Conceptually, the GC starts with global variables and goroutine stacks and traces all pointers to find all reachable memory. Unreachable memory is discarded. What makes this case harder is that we need to not only track pointers, we need to also look at the slice information to turn the pointer to the backing array into a sort of bounded pointer: a pointer to only part of the object, not all of it. That means that the GC has to understand slice structures, which are more complex than pointers. It means that the compiler has to build slice structures in a way that the GC can understand, which it currently does not do. That may sound simple, but currently the compiler splits up local slices into three independent local variables, and that would either become impossible or would require significantly more data to be recorded for the GC. Another wrinkle is that the current memory allocator does not support shrinking memory allocations at all, since that currently never happens. The allocator is based on storing objects of the same size together, so it's not easy to split an existing object into smaller sizes. That said, very large objects do have to be handled differently and it might be more feasible to shrink those objects; I'm not sure. So those are some of the reasons why it is hard. 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/CAOyqgcV0kwkYKdy_gwnK7UXisAkiSUTHb6wkN8iZyHN0vXXuAw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] Is it a good idea to use atomic operations in setter and getter methods?
For example:
type Page struct {
views uint32
}
func (page *Page) SetViews(n uint32) {
atomic.StoreUint32(, n)
}
func (page *Page) Views() uint32 {
return atomic.LoadUint32()
}
Keith Randall and Ian Lance Taylor said that atomic.Load is a
memory_order_acquire
and atomic.Store is memory_order_release
, so there
is no memory order guarantees
between the following two calls, I think:
atomic.StoreUint32(, n)
atomic.LoadUint32()
In other words, the load result might not reflect the latest value of
page.views.
On the contrary, the memory order between the following two calls
is guaranteed to be as their order shown in code.
atomic.LoadUint32()
atomic.StoreUint32(, n)
Is my understanding right?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/51583b07-7f1d-4fad-86c6-38a19495b8d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Does reducing capacity of a slice return memory?
> Basically, it's hard to be sure that there isn't any other slice somewhere that might permit references to that trailing memory Ian, I am kind of curious about this case. I understand that "hard" is not "impossible", but still - if I copy the needed part to a smaller array, how does the GC knows that there are no more slices pointing to a part of an old allocation? Andrey On Thursday, July 18, 2019 at 9:16:27 AM UTC-6, Ian Lance Taylor wrote: > > On Thu, Jul 18, 2019 at 7:24 AM robfig > > wrote: > > > > I was curious if reducing the capacity of slice makes that memory > available to be reclaimed? > > > > (1) Reducing capacity using a three-index: > > > > var s = make([]int64, 1e9) > > ... add data to s, keeping a count .. > > s = s[:n:n] // reduce length and capacity to number of items read > > > > (2) Reducing capacity by slicing off the front, as happens when using > slice as a queue > > > > var s []int64 > > s = append(s, 1, 2, 3, 4, 5) > > s = s[5:] > > > > Should I be careful to allocate a new slice and copy over, if I want to > avoid that memory being pinned until the original slice goes out of scope? > > In the current implementations, reducing the capacity of the slice > does not cause the trailing memory to be released. Basically, it's > hard to be sure that there isn't any other slice somewhere that might > permit references to that trailing memory. > > There has been some discussion of changing the garbage collector to > support this, but it's not simple. > > 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/20609e66-8733-4318-98c3-6bb5d4a953ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Panic not recovered inside my panic recover function
see https://go101.org/article/panic-and-recover-more.html for detailed
explanations.
On Thursday, July 18, 2019 at 12:52:13 PM UTC+8, ZPL wrote:
>
> Sorry for the bad formatting.
>
> > recover must be called directly by a deferred function
> func logPanic() {
> defer func() {
> if err := recover(); err != nil {
>fmt.Println("got panic")
>return
> }
> }()
> }
> This still not working.
>
>
>
> From https://blog.golang.org/defer-panic-and-recover,
>
> *Recover* is a built-in function that regains control of a panicking
> goroutine. Recover is only useful inside deferred functions. During normal
> execution, a call to recover will return nil and have no other effect. *If
> the current goroutine is panicking, a call to recover will capture the
> value given to panic and resume normal execution.*
> I think I didn't break any rules.
>
>
> Ian Lance Taylor > 于2019年7月17日周三 下午9:59写道：
>
>> On Wed, Jul 17, 2019 at 5:11 AM Tamás Gulácsi > > wrote:
>> >
>> > The "recover()" call must be in the deferred part.
>>
>> Yes, as the spec says, recover must be called directly by a deferred
>> function.
>>
>> When sending code to this list, please use a link to the Go playground
>> or use plain text. The highlighted text with a black background is
>> unreadable. Thanks.
>>
>> 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/Ok40EBXxQ2Q/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> golan...@googlegroups.com .
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXUWYdq%3DzSSw4V_HvNzrNpnrt1awEZbRFca0f6qHoBdsQ%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> --刘志平
>
--
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/08bc384e-3650-4050-8704-17bc5c6936a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Does reducing capacity of a slice return memory?
On Thu, Jul 18, 2019 at 7:24 AM robfig wrote: > > I was curious if reducing the capacity of slice makes that memory available > to be reclaimed? > > (1) Reducing capacity using a three-index: > > var s = make([]int64, 1e9) > ... add data to s, keeping a count .. > s = s[:n:n] // reduce length and capacity to number of items read > > (2) Reducing capacity by slicing off the front, as happens when using slice > as a queue > > var s []int64 > s = append(s, 1, 2, 3, 4, 5) > s = s[5:] > > Should I be careful to allocate a new slice and copy over, if I want to avoid > that memory being pinned until the original slice goes out of scope? In the current implementations, reducing the capacity of the slice does not cause the trailing memory to be released. Basically, it's hard to be sure that there isn't any other slice somewhere that might permit references to that trailing memory. There has been some discussion of changing the garbage collector to support this, but it's not simple. 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/CAOyqgcUzK4g1RK9XmGLN%3DcSAEqdby2u1xta12-wECvnOFeL4tg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Build kubernetes with gollvm
Hi Than Thank you for your fix. I have some curious about the difference between the main Go compiler and gollvm. I read gollvm's readme and know that the main difference comes from the efficiency of GC. Is the other difference causes the symbol undefined reference as you mentioned above? Or some bugs (or library version skew) that will be fixed in the future. Thanks, Ting -- 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/43e2e2b9-9a1e-4e22-8349-c6ed4d45df72%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
