Re: [go-nuts] Build kubernetes with gollvm

[Yuan Ting]

 Sorry to have troubled you again, I found that many famous Go projects 
also import github.com/modern-go/reflect2 , such as kubernetes and moby. 
According to the second paragraph in your explanation, these popular 
projects will also failed in compilation. I think this may be a big 
challenge for gccgo/gollvm's promotion.

To solve this compiler-sensitive problem, the way I can come up with is 
replacing all unsafe mechanisms as mentioned above in reflect2 to safe or 
standard mechanisms (and may go against the purpose of reflect2). I'm not 
familiar with runtime, but is it possible to support the same symbol in 
gccgo/gollvm style?

Best, 
Ting 

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/47ff4ccd-cabf-419c-88a1-6e5687b9ce18%40googlegroups.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Michel Levieux]

Hello everyone,

I might be saying something stupid but I found this topic really
interesting and I was wondering:

Instead of trying to get the notion of "slice" to replace that of "pointer"
in the compiler/runtime reference frame, wouldn't it be possible / less
complex to keep track of the largest subslice of a slice that is currently
used? Again this is not applicable for slices of elements of complex type.
But at least with native basic Go types, it would become possible to say:

I have a slice S that is shared by N goroutines / different parts of the
program, the largest subslice of S referenced right now is T, and T is less
than X% of the length of S, so we can retrieve the remaining memory to the
OS.

Michel,

Le ven. 19 juil. 2019 à 07:15, Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> a écrit :

> 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
> 
> .
>

-- 
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/CANgi335naByTb%3DtsY1oEyKQ_mEN6%2BLyFqFyc%2BRHhMfsxJ4UWow%40mail.gmail.com.

[go-nuts] ioutil.ReadDir error

[rob]

I have this in my code

  files, err := ioutil.ReadDir(CleanDirName)

  if err != nil {

    log.Println(err)

  }

Occasionally I have a symlink to another computer that goes stale, with 
this error:


  lstat [symlinkname] stale NFS file handle

When this happens, ReadDir does not return any other files in the 
slice.  I would like it to.  Is there any way for me to get it to do that?


--rob solomon

--
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/0bdda613-3f10-1c5c-eba9-a2f70ccd517d%40gmail.com.

[go-nuts] ioutil.ReadDir

[rob]

I forgot to say that this is on linuxmint 19.1, 64 bit

--
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/f19bae33-923f-77ca-26fc-42c71a22fcc8%40gmail.com.

Re: [go-nuts] ioutil.ReadDir error

[Steven Hartland]

If you want this behavior you'll need to use the lower level methods in 
the os package .


    Regards
    Steve

On 19/07/2019 11:54, rob wrote:

I have this in my code

  files, err := ioutil.ReadDir(CleanDirName)

  if err != nil {

    log.Println(err)

  }

Occasionally I have a symlink to another computer that goes stale, 
with this error:


  lstat [symlinkname] stale NFS file handle

When this happens, ReadDir does not return any other files in the 
slice.  I would like it to.  Is there any way for me to get it to do 
that?


--rob solomon



--
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/de4ad0cc-f0d2-80bc-af11-fe2e51b41e74%40multiplay.co.uk.

[go-nuts] gomobile wiki empty

[Johan Torås Halseth]

Not sure if it has moved, but I noticed that the gomobile wiki on GitHub 
(which plenty of docs link to) is 
empty: https://github.com/golang/go/wiki/Mobile

Deleted by mistake?

-- 
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/93256ed5-9745-4085-a56d-b734a48d64e5%40googlegroups.com.

Re: [go-nuts] gomobile wiki empty

[Ian Lance Taylor]

On Fri, Jul 19, 2019 at 5:48 AM Johan Torås Halseth  wrote:
>
> Not sure if it has moved, but I noticed that the gomobile wiki on GitHub 
> (which plenty of docs link to) is empty: 
> https://github.com/golang/go/wiki/Mobile
>
> Deleted by mistake?

Thanks.  Someone deleted the page yesterday.  I recreated it.

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/CAOyqgcX92SY-qaG7RJKHA_CWgiPOXuntty7WJB7zb%3DrfcaXPtw%40mail.gmail.com.

[go-nuts] Need help to learn go lang

[veereshreddy . r]

would anyone help me out how to learn go lang more practically , may be 
some resources . I want to understand go lang more practically , with some 
great examples.

thank you!

-- 
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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%40googlegroups.com.

Re: [go-nuts] Need help to learn go lang

[Brian Hatfield]

Hi Veereshreddy!

Welcome to Go!

Here's a collection of links that I put together for some of my teammates
who are new to Go:

Basics / Introduction to Go

GoByExample  is a great resource if you've got
experience with 2+ programming languages already. It quickly showcases
langauge syntax and features, but is relatively spartan in its presentation.

The Little Go Book  is a
more thorough book-style approach to Go for folks with less diverse
programming language experience, or for folks who find GoByExample to be
too spartan.

The Golang Tour  is the official
interactive introduction to Go. It leverages the Go playground, which lets
you run Go right in your web browser.
Intermediate
Go

These links deal with the practicalities of writing Go, and
encourage/discourage various implementation patterns observed in real world
use.

Effective Go  is officially
provided documentation that gives tips for writing clear, idiomatic Go
code. "Effective Go" is generally regarded in the Go community as
particularly helpful.

Go Code Review Comments
 is a laundry list of
common mistakes, not a comprehensive style guide. It's great for beginners
and advanced programmers as it explains the rationale behind its guidance.

Practical Go: Real World Advice
 presents
an excellent overview of the practice of software engineering in Go. Some
overlap with Effective Go and Code Review Comments, but with more
explanation and memorable quotes to describe patterns.

On Fri, Jul 19, 2019 at 9:39 AM  wrote:

> would anyone help me out how to learn go lang more practically , may be
> some resources . I want to understand go lang more practically , with some
> great examples.
>
> thank you!
>
> --
> 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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%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/CANGiwgb7LhxGLF4GcH0bb2h4c5_k%3DVjcC8qKvS6vJDOisd16Fw%40mail.gmail.com.

Re: [go-nuts] Need help to learn go lang

[Brian Hatfield]

Veeresh,

Out of the links I provided, The Little Go Book is the closest to a "new
programmer" book, but I don't think it really meets that need. Hopefully
others on this list are aware of a good resource for "new to programming
and want to try Go" and can link you to one!

Good luck,
Brian

On Fri, Jul 19, 2019 at 9:50 AM Veeresh Reddy 
wrote:

> Thanks much . To be honest I have not wrote any code so far but I wanted
> to start of with Go Lang . Pleade suggest me some accordingly .
>
> On Fri, 19 Jul 2019, 7:15 pm Brian Hatfield,  wrote:
>
>> Hi Veereshreddy!
>>
>> Welcome to Go!
>>
>> Here's a collection of links that I put together for some of my teammates
>> who are new to Go:
>>
>> Basics / Introduction to Go
>>
>> GoByExample  is a great resource if you've got
>> experience with 2+ programming languages already. It quickly showcases
>> langauge syntax and features, but is relatively spartan in its presentation.
>>
>> The Little Go Book  is a
>> more thorough book-style approach to Go for folks with less diverse
>> programming language experience, or for folks who find GoByExample to be
>> too spartan.
>>
>> The Golang Tour  is the official
>> interactive introduction to Go. It leverages the Go playground, which lets
>> you run Go right in your web browser.
>>
>> Intermediate
>> Go
>>
>> These links deal with the practicalities of writing Go, and
>> encourage/discourage various implementation patterns observed in real world
>> use.
>>
>> Effective Go  is officially
>> provided documentation that gives tips for writing clear, idiomatic Go
>> code. "Effective Go" is generally regarded in the Go community as
>> particularly helpful.
>>
>> Go Code Review Comments
>>  is a laundry list
>> of common mistakes, not a comprehensive style guide. It's great for
>> beginners and advanced programmers as it explains the rationale behind its
>> guidance.
>>
>> Practical Go: Real World Advice
>>  presents
>> an excellent overview of the practice of software engineering in Go. Some
>> overlap with Effective Go and Code Review Comments, but with more
>> explanation and memorable quotes to describe patterns.
>>
>> On Fri, Jul 19, 2019 at 9:39 AM  wrote:
>>
>>> would anyone help me out how to learn go lang more practically , may be
>>> some resources . I want to understand go lang more practically , with some
>>> great examples.
>>>
>>> thank you!
>>>
>>> --
>>> 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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%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/CANGiwgbWEsMZaU66zn-eN2%3Dcm8sOp_tGwRd6-pC%3Di9DJiahcOg%40mail.gmail.com.

Re: [go-nuts] Build kubernetes with gollvm

[Ian Lance Taylor]

On Fri, Jul 19, 2019 at 1:11 AM Yuan Ting  wrote:
>
>  Sorry to have troubled you again, I found that many famous Go projects also 
> import github.com/modern-go/reflect2 , such as kubernetes and moby. According 
> to the second paragraph in your explanation, these popular projects will also 
> failed in compilation. I think this may be a big challenge for gccgo/gollvm's 
> promotion.
>
> To solve this compiler-sensitive problem, the way I can come up with is 
> replacing all unsafe mechanisms as mentioned above in reflect2 to safe or 
> standard mechanisms (and may go against the purpose of reflect2). I'm not 
> familiar with runtime, but is it possible to support the same symbol in 
> gccgo/gollvm style?

Simply supporting runtime.typelinks is not enough.  The reflect
package is closely tied to the compiler implementation.  The reflect
package is not identical in the gc library and the GoLLVM library.  If
people need reflect2 to work with GoLLVM, then the only workable
option is for the reflect2 authors to write a version of their package
that uses the gccgo build tag to build a version that works with
GoLLVM.  Perhaps you could help them with that.  Sorry this isn't very
helpful.  I don't really understand why people are using the package.

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/CAOyqgcWZr%2BLjw8YQHHrHxN3AvhPi%2BNUyN3-F7ddvc7wpnSg3HQ%40mail.gmail.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Ian Lance Taylor]

I'm not sure what to say.  If someone wants to write up and work on a
detailed implementation proposal, that is fine.  Go for it.  As I said
earlier, I think it would be hard.  I'll add that I don't think that
the difficulty would pay off in terms of the amount of real code that
it would help.  There is a lot of other hard work that could be done
in the compiler that would, I think, help many more programs.

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/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Space A.]

Unless there are financial reports published for passed years, my personal 
opinion is that accurate term could be "use of official position or office 
for personal gain". Quite common thing to such a big companies, tbh.
Oh, and don't forget "If you are independent artist tried to make something 
for community - your problem, sincerely yours, Google"


On Friday, July 19, 2019 at 8:35:53 AM UTC+3, andrey mirtchovski wrote:
>
> 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 golan...@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/c7e6bcea-659a-4d3e-8753-07757b797b62%40googlegroups.com.

Re: [go-nuts] Need help to learn go lang

[Veeresh Reddy]

Thanks much . To be honest I have not wrote any code so far but I wanted to
start of with Go Lang . Pleade suggest me some accordingly .

On Fri, 19 Jul 2019, 7:15 pm Brian Hatfield,  wrote:

> Hi Veereshreddy!
>
> Welcome to Go!
>
> Here's a collection of links that I put together for some of my teammates
> who are new to Go:
>
> Basics / Introduction to Go
>
> GoByExample  is a great resource if you've got
> experience with 2+ programming languages already. It quickly showcases
> langauge syntax and features, but is relatively spartan in its presentation.
>
> The Little Go Book  is a
> more thorough book-style approach to Go for folks with less diverse
> programming language experience, or for folks who find GoByExample to be
> too spartan.
>
> The Golang Tour  is the official
> interactive introduction to Go. It leverages the Go playground, which lets
> you run Go right in your web browser.
>
> Intermediate
> Go
>
> These links deal with the practicalities of writing Go, and
> encourage/discourage various implementation patterns observed in real world
> use.
>
> Effective Go  is officially
> provided documentation that gives tips for writing clear, idiomatic Go
> code. "Effective Go" is generally regarded in the Go community as
> particularly helpful.
>
> Go Code Review Comments
>  is a laundry list
> of common mistakes, not a comprehensive style guide. It's great for
> beginners and advanced programmers as it explains the rationale behind its
> guidance.
>
> Practical Go: Real World Advice
>  presents
> an excellent overview of the practice of software engineering in Go. Some
> overlap with Effective Go and Code Review Comments, but with more
> explanation and memorable quotes to describe patterns.
>
> On Fri, Jul 19, 2019 at 9:39 AM  wrote:
>
>> would anyone help me out how to learn go lang more practically , may be
>> some resources . I want to understand go lang more practically , with some
>> great examples.
>>
>> thank you!
>>
>> --
>> 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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%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/CAEZF3R8FQ%2BL2z3O7W0nTJZidj%3DyQPCxEFQmwStikeodP2iN0rQ%40mail.gmail.com.

Re: [go-nuts] Need help to learn go lang

[Michael Jones]

Veeresh,

Welcome to the world of programming. It is a beautiful world and has been
my joy for fifty years. It is magical to have a robot friend to multiply
your abilities by millions of times.

Learning about programming at the very start is a small group of tasks:
learning a few details like “where do I type” and “how do I start it” and
understanding the nature of the magic; unlike the Sourcer’s Apprentice in
Fantasia you can’t just point, the robot is faithful but not so smart. You
may be surprised at the need to give very simple commands.

Many people learn best by example. The Golang Tour that Brian mentioned has
this virtue. Not only can you see what’s happening, but you can type
changes right there to try it your way. Give that a quick look.

I’ve taught students/classes but long ago. I do not know what’s the best
“new person learning to program a computer” guide out there now, or if any
of those use Go as their environment. I learned alone in the 4th grade (age
ten) using grim tools for a child (keypunch, FORTRAN, big computer centers)
— so whatever you do will be better!

It is not hard, is fun, and offers many rewards.

Good luck,
Michael

On Fri, Jul 19, 2019 at 7:02 AM Brian Hatfield  wrote:

> Veeresh,
>
> Out of the links I provided, The Little Go Book is the closest to a "new
> programmer" book, but I don't think it really meets that need. Hopefully
> others on this list are aware of a good resource for "new to programming
> and want to try Go" and can link you to one!
>
> Good luck,
> Brian
>
> On Fri, Jul 19, 2019 at 9:50 AM Veeresh Reddy 
> wrote:
>
>> Thanks much . To be honest I have not wrote any code so far but I wanted
>> to start of with Go Lang . Pleade suggest me some accordingly .
>>
>> On Fri, 19 Jul 2019, 7:15 pm Brian Hatfield, 
>> wrote:
>>
>>> Hi Veereshreddy!
>>>
>>> Welcome to Go!
>>>
>>> Here's a collection of links that I put together for some of my
>>> teammates who are new to Go:
>>>
>>> Basics / Introduction to Go
>>>
>>> GoByExample  is a great resource if you've
>>> got experience with 2+ programming languages already. It quickly showcases
>>> langauge syntax and features, but is relatively spartan in its presentation.
>>>
>>> The Little Go Book  is
>>> a more thorough book-style approach to Go for folks with less diverse
>>> programming language experience, or for folks who find GoByExample to be
>>> too spartan.
>>>
>>> The Golang Tour  is the official
>>> interactive introduction to Go. It leverages the Go playground, which lets
>>> you run Go right in your web browser.
>>>
>>> Intermediate
>>> Go
>>>
>>> These links deal with the practicalities of writing Go, and
>>> encourage/discourage various implementation patterns observed in real world
>>> use.
>>>
>>> Effective Go  is officially
>>> provided documentation that gives tips for writing clear, idiomatic Go
>>> code. "Effective Go" is generally regarded in the Go community as
>>> particularly helpful.
>>>
>>> Go Code Review Comments
>>>  is a laundry
>>> list of common mistakes, not a comprehensive style guide. It's great for
>>> beginners and advanced programmers as it explains the rationale behind its
>>> guidance.
>>>
>>> Practical Go: Real World Advice
>>>  
>>> presents
>>> an excellent overview of the practice of software engineering in Go. Some
>>> overlap with Effective Go and Code Review Comments, but with more
>>> explanation and memorable quotes to describe patterns.
>>>
>>> On Fri, Jul 19, 2019 at 9:39 AM  wrote:
>>>
 would anyone help me out how to learn go lang more practically , may be
 some resources . I want to understand go lang more practically , with some
 great examples.

 thank you!

 --
 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/4cb7eae4-b6d2-4454-9d4a-2fe7790cf685%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/CANGiwgbWEsMZaU66zn-eN2%3Dcm8sOp_tGwRd6-pC%3Di9DJiahcOg%4

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Michael Jones]

There is a difference in the meanings of terms in this discussion, maybe
that’s confusing to some. (That is, Ian went right to the heart of the
matter but maybe a simpler fact needs to be made plain to others.)

When you think of the memory used by a slice and of maybe using less of it
and “returning” the rest, like putting uneaten food away for tomorrow,
you’re making several big demands.

You demand severabity, that half a TV set is a reasonable thing to discuss,
like half a pie. In fact that backing array was created by the allocator as
“256 bytes you can use, with other info you don’t know about somewhere.” To
chop off half and “give it back” is not part of the contract. The contract
is: use it until you’re done with it. (The whole TV, because of wires and
glass bits).

One alternative is to make 256 allocations of the small parts, then
allocate an array as pointers to each little part. Then you can reshape the
array and free the extra parts. This freedom pays a tax in many ways, and
always pays it in the normal case.

But in the efficient single group allocation style (Go, C, C++, ...) the
desire to return part of a monolithic allocation is a major burden. Ian
went right to the elements of that burden. But since the follow ups still
wanted the burden I thought maybe a reminder of why it is hard would help.

On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor  wrote:

> I'm not sure what to say.  If someone wants to write up and work on a
> detailed implementation proposal, that is fine.  Go for it.  As I said
> earlier, I think it would be hard.  I'll add that I don't think that
> the difficulty would pay off in terms of the amount of real code that
> it would help.  There is a lot of other hard work that could be done
> in the compiler that would, I think, help many more programs.
>
> 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/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com
> .
>
-- 

*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/CALoEmQxJOkrYvT7yjmEFGr%2BT_xFiairSgYmUp%3Drx2EZTqVPLWw%40mail.gmail.com.

Re: [go-nuts] Re: About the Google logo on the new Go website

[Michael Jones]

You sure seem eager to post negative things from your gmail account. Do you
troll only, or is there anything of substance?

If there is something about the Go language or computer programming that
you wish to share it would be welcome: perhaps open source software you’ve
written and want developers to know about, questions for the experts here,
or maybe job positions you have for developers in your company. This is the
place for such matters.

On Fri, Jul 19, 2019 at 8:21 AM Space A.  wrote:

> Unless there are financial reports published for passed years, my personal
> opinion is that accurate term could be "use of official position or office
> for personal gain". Quite common thing to such a big companies, tbh.
> Oh, and don't forget "If you are independent artist tried to make
> something for community - your problem, sincerely yours, Google"
>
>
> On Friday, July 19, 2019 at 8:35:53 AM UTC+3, andrey mirtchovski wrote:
>>
>> 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 golan...@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/c7e6bcea-659a-4d3e-8753-07757b797b62%40googlegroups.com
> 
> .
>
-- 

*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/CALoEmQypkG%2BtHPiJFgZYmGHjiEAhgOtTPGuPHi8Nntt1TFi9wQ%40mail.gmail.com.

[go-nuts] Build issues on FreeBSD ZoF "unexpected stale targets"

[mat . macy]

I'm not sure where to ask this since this isn't actually a Go bug. Go 1.12, 
1.1, etc build fine on FreeBSD with ZFS in base. However, with the ZFS 
rebased to ZFS on Linux I'm seeing issues that I can only reproduce 
building Go. I either see:

from one run:
go install encoding/gob: copying /tmp/go-build309923892/b103/_pkg_.a to 
/testpool/freebsd-ports/lang/go/work/go/pkg/freebsd_amd64/encoding/gob.a: 
read /tmp/go-build309923892/b103/_pkg_.a: bad address

another:
cmd/pack
cmd/vendor/github.com/google/pprof/internal/elfexec
go install go/types: copying /tmp/go-build100514402/b143/_pkg_.a to 
/testpool/freebsd-ports/lang/go/work/go/pkg/freebsd_amd64/go/types.a: read 
/tmp/go-build100514402/b143/_pkg_.a: bad address
cmd/go/internal/cache

And dtrace doesn't show any system call returning EFAULT when this happens. 
So maybe something in libc? Unclear. 


Or from another run:
HASH[build runtime/internal/sys]
HASH[build runtime/internal/sys]: "go1.12.7"
HASH[build runtime/internal/sys]: "compile\n"
HASH[build runtime/internal/sys]: "goos freebsd goarch amd64\n"
HASH[build runtime/internal/sys]: "import \"runtime/internal/sys\"\n"
HASH[build runtime/internal/sys]: "omitdebug false standard true local 
false prefix \"\"\n"
HASH[build runtime/internal/sys]: "modinfo \"\"\n"
HASH[build runtime/internal/sys]: "compile go1.12.7 [] []\n"
HASH[build runtime/internal/sys]: "GO$GOARCH=\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/arch.go: 
d9b0b7e72538d421b2607acaba60ca49f20ef584b3d1d191c6729e35fbb8101d
HASH[build runtime/internal/sys]: "file arch.go 2bC35yU41CGyYHrKumDK\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/arch_amd64.go: 
1301163254cfb431f101054609fd549f284be1ea42c0bfb3be0ba4b3dddac13d
HASH[build runtime/internal/sys]: "file arch_amd64.go 
EwEWMlTPtDHxAQVGCf1U\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/intrinsics.go: 
8b469a461e1d983706e0b3635715ce70691adc5db7c4e067b88cc59f40cd66f4
HASH[build runtime/internal/sys]: "file intrinsics.go 
i0aaRh4dmDcG4LNjVxXO\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/stubs.go: 
23b3e5c631b086fe7a2dec4bf044600e034bf6a8eeb25e0a19efc4ce6311423d
HASH[build runtime/internal/sys]: "file stubs.go I7PlxjGwhv56LexL8ERg\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/sys.go: 
55e021891200a7e6a5c371c8a1ab71b6c15aeb16ea6c1b192185d17df8c8b18f
HASH[build runtime/internal/sys]: "file sys.go VeAhiRIAp-alw3HIoatx\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/zgoarch_amd64.go:
 
6f2fa4ebe8999a3b7cfe3ead6e24b8356ed842292f23cb1b4f995c0b5b45126b
HASH[build runtime/internal/sys]: "file zgoarch_amd64.go 
by-k6-iZmjt8_j6tbiS4\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/zgoos_freebsd.go:
 
89479e2fc5aba8e27f05a11c1b0f2e333c6f203aa502497d7be38aa6b5819493
HASH[build runtime/internal/sys]: "file zgoos_freebsd.go 
iUeeL8WrqOJ_BaEcGw8u\n"
HASH 
/testpool/freebsd-ports/lang/go/work/go/src/runtime/internal/sys/zversion.go: 
492d4832fcbc095d59151e03f7b144693586a844678f2033fc73928d9093687d
HASH[build runtime/internal/sys]: "file zversion.go SS1IMvy8CV1ZFR4D97FE\n"
HASH[build runtime/internal/sys]: 
7c65aacaf2f596f2ec3d978ef53e6ff58dd327a8a91976438813cad31190ee93
HASH subkey 
7c65aacaf2f596f2ec3d978ef53e6ff58dd327a8a91976438813cad31190ee93 "stdout" = 
75d0847bbde28d271e659eeb7d91770e854c2ed5c3a127b9109c3f001f0df627
runtime/internal/sys true
go tool dist: unexpected stale targets reported by 
/testpool/freebsd-ports/lang/go/work/go/pkg/tool/freebsd_amd64/go_bootstrap 
list -gcflags="" -ldflags="" for [cmd/asm cmd/cgo cmd/compile cmd/link 
runtime/internal/sys]:
STALE runtime/internal/sys: not installed but available in build 
cache

and another:
go tool dist: unexpected stale targets reported by 
/testpool/freebsd-ports/lang/go/work/go/pkg/tool/freebsd_amd64/go_bootstrap 
list -gcflags="" -ldflags="" for [cmd/asm cmd/cgo cmd/compile cmd/link 
runtime/internal/sys]:
STALE cmd/asm: stale dependency: internal/race
STALE cmd/cgo: stale dependency: internal/race
STALE cmd/compile: stale dependency: internal/race
STALE cmd/link: stale dependency: math/bits

*** Error code 2

Could someone tell me what it's doing when the first type of failure occurs 
and what the STALE error means? I've seen the latter in past issues, but 
there was no indication of what that was a symptom of.

Thanks.
-M

-- 
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/0cc39c5c-5e3b-4f73-8b48-658152d4b99a%40googlegroups.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Andrey Tcherepanov]

My suggestion was not to make "the kitchen" work harder by marking parts of 
the hamburger to be good for the consumption, no. My suggestion was to 
recycle bitten hamburger out and put just the bitten piece aside in a doggy 
bag, sorry.

A.

On Friday, July 19, 2019 at 1:08:51 PM UTC-6, Michael Jones wrote:
>
> There is a difference in the meanings of terms in this discussion, maybe 
> that’s confusing to some. (That is, Ian went right to the heart of the 
> matter but maybe a simpler fact needs to be made plain to others.)
>
> When you think of the memory used by a slice and of maybe using less of it 
> and “returning” the rest, like putting uneaten food away for tomorrow, 
> you’re making several big demands. 
>
> You demand severabity, that half a TV set is a reasonable thing to 
> discuss, like half a pie. In fact that backing array was created by the 
> allocator as “256 bytes you can use, with other info you don’t know about 
> somewhere.” To chop off half and “give it back” is not part of the 
> contract. The contract is: use it until you’re done with it. (The whole TV, 
> because of wires and glass bits).
>
> One alternative is to make 256 allocations of the small parts, then 
> allocate an array as pointers to each little part. Then you can reshape the 
> array and free the extra parts. This freedom pays a tax in many ways, and 
> always pays it in the normal case. 
>
> But in the efficient single group allocation style (Go, C, C++, ...) the 
> desire to return part of a monolithic allocation is a major burden. Ian 
> went right to the elements of that burden. But since the follow ups still 
> wanted the burden I thought maybe a reminder of why it is hard would help. 
>
> On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor  > wrote:
>
>> I'm not sure what to say.  If someone wants to write up and work on a
>> detailed implementation proposal, that is fine.  Go for it.  As I said
>> earlier, I think it would be hard.  I'll add that I don't think that
>> the difficulty would pay off in terms of the amount of real code that
>> it would help.  There is a lot of other hard work that could be done
>> in the compiler that would, I think, help many more programs.
>>
>> 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 golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com
>> .
>>
> -- 
>
> *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/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com.

[go-nuts] Re: About the Google logo on the new Go website

[Cassandra Salisbury]

I encourage everyone to take a look at the code of conduct 
. I have had multiple reports from this 
particular thread. 

I understand the desire to express opinions and thoughts, but please note 
that you should be doing this* within the bounds of our Code of Conduct 
.*

*As a reminder*

Our Standards

Examples of behavior that contributes to creating a positive environment 
include:

   - Using welcoming and inclusive language
   - Being respectful of differing viewpoints and experiences
   - Gracefully accepting constructive criticism
   - Focusing on what is best for the community
   - Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

   - The use of sexualized language or imagery and unwelcome sexual 
   attention or advances
   - Trolling, insulting/derogatory comments, and personal or political 
   attacks
   - Public or private harassment
   - Publishing others’ private information, such as a physical or 
   electronic address, without explicit permission
   - Other conduct which could reasonably be considered inappropriate in a 
   professional setting

Thank you, 
Cassandra

On Monday, July 15, 2019 at 8:40:19 AM UTC-7, 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/17234e97-22de-4002-9ed6-541df4f02d5d%40googlegroups.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Michael Jones]

Yes! That always works at the application level. Write an “inspector” that
examines things, duplicating and copying the live parts.

I do that in several of my long running math apps, where my pool of
big.Ints end up with 50-100 thousand digit allocations in a big because of
one giant multiply...I examine them as I recycle and manage this. Makes a
big difference.

But doing it when you know the situation is easy. It’s having the compiler
“just know” that is so challenging. (Unless you box everything like
Java...and that’s an expensive path)

On Fri, Jul 19, 2019 at 12:43 PM Andrey Tcherepanov <
xnow4fippy...@sneakemail.com> wrote:

> My suggestion was not to make "the kitchen" work harder by marking parts
> of the hamburger to be good for the consumption, no. My suggestion was to
> recycle bitten hamburger out and put just the bitten piece aside in a doggy
> bag, sorry.
>
> A.
>
> On Friday, July 19, 2019 at 1:08:51 PM UTC-6, Michael Jones wrote:
>>
>> There is a difference in the meanings of terms in this discussion, maybe
>> that’s confusing to some. (That is, Ian went right to the heart of the
>> matter but maybe a simpler fact needs to be made plain to others.)
>>
>> When you think of the memory used by a slice and of maybe using less of
>> it and “returning” the rest, like putting uneaten food away for tomorrow,
>> you’re making several big demands.
>>
>> You demand severabity, that half a TV set is a reasonable thing to
>> discuss, like half a pie. In fact that backing array was created by the
>> allocator as “256 bytes you can use, with other info you don’t know about
>> somewhere.” To chop off half and “give it back” is not part of the
>> contract. The contract is: use it until you’re done with it. (The whole TV,
>> because of wires and glass bits).
>>
>> One alternative is to make 256 allocations of the small parts, then
>> allocate an array as pointers to each little part. Then you can reshape the
>> array and free the extra parts. This freedom pays a tax in many ways, and
>> always pays it in the normal case.
>>
>> But in the efficient single group allocation style (Go, C, C++, ...) the
>> desire to return part of a monolithic allocation is a major burden. Ian
>> went right to the elements of that burden. But since the follow ups still
>> wanted the burden I thought maybe a reminder of why it is hard would help.
>>
>> On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor 
>> wrote:
>>
>>> I'm not sure what to say.  If someone wants to write up and work on a
>>> detailed implementation proposal, that is fine.  Go for it.  As I said
>>> earlier, I think it would be hard.  I'll add that I don't think that
>>> the difficulty would pay off in terms of the amount of real code that
>>> it would help.  There is a lot of other hard work that could be done
>>> in the compiler that would, I think, help many more programs.
>>>
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com
>>> .
>>>
>> --
>>
>> *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/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com
> 
> .
>
-- 

*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/CALoEmQy%3DRtfLzFqUnnzng-dba2mm0kx0o7hc2pTUDT_RTb1UpA%40mail.gmail.com.

[go-nuts] Re: Build issues on FreeBSD ZoF "unexpected stale targets"

[B Carr]

What does this part mean? "...with the ZFS rebased to ZFS on Linux..."


On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote:
>
> I'm not sure where to ask this since this isn't actually a Go bug. Go 
> 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However, with the 
> ZFS rebased to ZFS on Linux I'm seeing issues that I can only reproduce 
> building Go.
>

-- 
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/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%40googlegroups.com.

Re: [go-nuts] Re: Build issues on FreeBSD ZoF "unexpected stale targets"

[Steven Hartland]

Mat is actually running a non-standard kernel, with the ZFS filesystem 
from the core OS replaced with a ZFS version derived from Linux ZFS port.


I've not looked at the details of the port, but one suggestion would be 
do you see the same behaviour if you build on UFS volume while still 
running the kernel with the ZFS port.


This may indicate if a strange filesystem level issue is causing 
corruption or if the port has changed / broken a kernel feature go is 
relying on.


    Regards
    Steve
On 19/07/2019 22:01, B Carr wrote:


What does this part mean? "...with the ZFS rebased to ZFS on Linux..."


On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote:

I'm not sure where to ask this since this isn't actually a Go bug.
Go 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However,
with the ZFS rebased to ZFS on Linux I'm seeing issues that I can
only reproduce building Go.

--
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/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%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/2dc3cd67-9bd1-8ca7-df85-2f4436ecc103%40multiplay.co.uk.

[go-nuts] Re: Need help to learn go lang

[Ronny Bangsund]

Brian's list is good.

I started with the tour and picked relatively simple tools I wanted to 
write, then looked up what I needed as projects advanced. My list of GitHub 
Go projects is getting unwieldy now, a few years later. It's an addiction. 
Just start with simple projects and set some increasingly advanced goals as 
you learn. It doesn't matter if you're recreating something that exists if 
you're learning from it.

Reading the docs for the included packages should give you an idea of 
what's built in, and it covers a lot. The basics to fetch and serve HTTP, 
sending mail, doing RPC and most of what you're likely to need in crypto, 
although sometimes a 3rd party may provide an easier/better way to do 
things. If you're building web servers you may need some middleware too 
(neater REST endpoint setup, authentication, rate-limiting).

There's a newbie channel on the Gopher Slack (you have to join it manually, 
as you only start with #general) where you should be able to get some help 
with specifics. Just start something and ask as you get stuck!

-- 
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/6bd2bf85-55e5-4cc5-a87a-d2f5b0001e1a%40googlegroups.com.

[go-nuts] How to safely convert a pointer to *unsafe.Pointer

[julio]

Hello,

I would like to make sure that the following line of Go is a defined 
behavior:

 addr := (*unsafe.Pointer)((unsafe.Pointer)(&ptr))

I use it to perform atomic loads and stores to addr such as in this simple 
example: https://play.golang.org/p/DpDrRvTYMG8
It allows me not to use atomic.Value which performs two atomic operations 
and possible disable preemption (
https://golang.org/src/sync/atomic/value.go?s=1233:1269#L35).

Thanks for your help,
Julio

-- 
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/3bc36e02-c821-4241-b929-c9c5abd5b4b7%40googlegroups.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Andrey Tcherepanov]

I understand that it is very easy on application level... if programmer 
even thought about it. But my assumption is that compiler has some sort of 
liveness analysis, and it could be utilized here just to help with disposal 
of a bitten part.

Andrey

On Friday, July 19, 2019 at 2:48:57 PM UTC-6, Michael Jones wrote:
>
> Yes! That always works at the application level. Write an “inspector” that 
> examines things, duplicating and copying the live parts. 
>
> I do that in several of my long running math apps, where my pool of 
> big.Ints end up with 50-100 thousand digit allocations in a big because of 
> one giant multiply...I examine them as I recycle and manage this. Makes a 
> big difference. 
>
> But doing it when you know the situation is easy. It’s having the compiler 
> “just know” that is so challenging. (Unless you box everything like 
> Java...and that’s an expensive path)
>
> On Fri, Jul 19, 2019 at 12:43 PM Andrey Tcherepanov <
> xnow4f...@sneakemail.com > wrote:
>
>> My suggestion was not to make "the kitchen" work harder by marking parts 
>> of the hamburger to be good for the consumption, no. My suggestion was to 
>> recycle bitten hamburger out and put just the bitten piece aside in a doggy 
>> bag, sorry.
>>
>> A.
>>
>> On Friday, July 19, 2019 at 1:08:51 PM UTC-6, Michael Jones wrote:
>>>
>>> There is a difference in the meanings of terms in this discussion, maybe 
>>> that’s confusing to some. (That is, Ian went right to the heart of the 
>>> matter but maybe a simpler fact needs to be made plain to others.)
>>>
>>> When you think of the memory used by a slice and of maybe using less of 
>>> it and “returning” the rest, like putting uneaten food away for tomorrow, 
>>> you’re making several big demands. 
>>>
>>> You demand severabity, that half a TV set is a reasonable thing to 
>>> discuss, like half a pie. In fact that backing array was created by the 
>>> allocator as “256 bytes you can use, with other info you don’t know about 
>>> somewhere.” To chop off half and “give it back” is not part of the 
>>> contract. The contract is: use it until you’re done with it. (The whole TV, 
>>> because of wires and glass bits).
>>>
>>> One alternative is to make 256 allocations of the small parts, then 
>>> allocate an array as pointers to each little part. Then you can reshape the 
>>> array and free the extra parts. This freedom pays a tax in many ways, and 
>>> always pays it in the normal case. 
>>>
>>> But in the efficient single group allocation style (Go, C, C++, ...) the 
>>> desire to return part of a monolithic allocation is a major burden. Ian 
>>> went right to the elements of that burden. But since the follow ups still 
>>> wanted the burden I thought maybe a reminder of why it is hard would help. 
>>>
>>> On Fri, Jul 19, 2019 at 7:36 AM Ian Lance Taylor  
>>> wrote:
>>>
 I'm not sure what to say.  If someone wants to write up and work on a
 detailed implementation proposal, that is fine.  Go for it.  As I said
 earlier, I think it would be hard.  I'll add that I don't think that
 the difficulty would pay off in terms of the amount of real code that
 it would help.  There is a lot of other hard work that could be done
 in the compiler that would, I think, help many more programs.

 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 golan...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/golang-nuts/CAOyqgcVvDz1kRzpoKNtw5MDH%2BrFpsW6fLSqrT%3DS83JGhM_Y-%2BA%40mail.gmail.com
 .

>>> -- 
>>>
>>> *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/d371646c-1f7c-4df1-8077-14e40c25ae04%40googlegroups.com
>>  
>> 
>> .
>>
> -- 
>
> *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/fcc2cc7d-f18e-4313-85c3-c22eeb38c9f6%40googlegroups.com.

Re: [go-nuts] Re: Build issues on FreeBSD ZoF "unexpected stale targets"

[mat . macy]

On Friday, July 19, 2019 at 2:24:30 PM UTC-7, Steven Hartland wrote:
>
> Mat is actually running a non-standard kernel, with the ZFS filesystem 
> from the core OS replaced with a ZFS version derived from Linux ZFS port.
>
> I've not looked at the details of the port, but one suggestion would be do 
> you see the same behaviour if you build on UFS volume while still running 
> the kernel with the ZFS port.
>
> This may indicate if a strange filesystem level issue is causing 
> corruption or if the port has changed / broken a kernel feature go is 
> relying on.
>

Haven't tried UFS but he problem doesn't occur when using tmpfs for /tmp 
when using ZoF or when using the ZFS in base for /tmp. Trussing the build 
slows it down to the point where it succeeds. I attribute this to some sort 
of race in ZoF but not in "legacy" ZFS. vfsops and vnops are essentially 
the same as upstream so I'm really not sure what to look for.

-M
 

>
> Regards
> Steve
> On 19/07/2019 22:01, B Carr wrote:
>
>
> What does this part mean? "...with the ZFS rebased to ZFS on Linux..." 
>
>
> On Friday, July 19, 2019 at 1:37:02 PM UTC-6, mat...@gmail.com wrote: 
>>
>> I'm not sure where to ask this since this isn't actually a Go bug. Go 
>> 1.12, 1.1, etc build fine on FreeBSD with ZFS in base. However, with the 
>> ZFS rebased to ZFS on Linux I'm seeing issues that I can only reproduce 
>> building Go.
>>
> -- 
> 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/fb3ca79e-cd21-4b4f-ac6c-4e608825d26e%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/e5b4f8cf-6203-4a93-88fe-b4d61d83b12d%40googlegroups.com.

Re: [go-nuts] How to safely convert a pointer to *unsafe.Pointer

[Ian Lance Taylor]

On Fri, Jul 19, 2019 at 4:33 PM  wrote:
>
> I would like to make sure that the following line of Go is a defined behavior:
>
>  addr := (*unsafe.Pointer)((unsafe.Pointer)(&ptr))
>
> I use it to perform atomic loads and stores to addr such as in this simple 
> example: https://play.golang.org/p/DpDrRvTYMG8
> It allows me not to use atomic.Value which performs two atomic operations and 
> possible disable preemption 
> (https://golang.org/src/sync/atomic/value.go?s=1233:1269#L35).

Yes, that operation is defined.  As documented at
https://golang.org/pkg/unsafe, you can use unsafe.Pointer to convert
from a pointer to one type to a pointer to a different type.

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

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Ian Lance Taylor]

On Fri, Jul 19, 2019 at 5:17 PM Andrey Tcherepanov
 wrote:
>
> I understand that it is very easy on application level... if programmer even 
> thought about it. But my assumption is that compiler has some sort of 
> liveness analysis, and it could be utilized here just to help with disposal 
> of a bitten part.

The kind of liveness analysis done by the compiler is only helpful in
extremely limited circumstances: when the compiler can track the slice
from creation to destruction and when the slice never escapes in any
way.  I'm skeptical that such a case happens often enough to be worth
implementing.

(And even if we did implement it we would still have the
above-mentioned problem that the allocator doesn't support discarding
part of an allocation.)

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/CAOyqgcVw1CHe8LV_grVycMfxz2cp7273KcQU7GASvXCZ29-3pQ%40mail.gmail.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Andrey Tcherepanov]

Thanks Ian, 

But just to be clear - I do not want to discard _a part_. I want to discard 
a _whole big one_, copying a small needed part that is still "alive" aside. 
Allocator perform it's duties as usual -  allocate a new small array, and 
discard an old one. It is just that compiler invokes this code on defer it 
if knows that there is only one reference to the remaining part, and that 
part is "small"

A.

On Friday, July 19, 2019 at 6:43:41 PM UTC-6, Ian Lance Taylor wrote:
>
> On Fri, Jul 19, 2019 at 5:17 PM Andrey Tcherepanov 
> > wrote: 
> > 
> > I understand that it is very easy on application level... if programmer 
> even thought about it. But my assumption is that compiler has some sort of 
> liveness analysis, and it could be utilized here just to help with disposal 
> of a bitten part. 
>
> The kind of liveness analysis done by the compiler is only helpful in 
> extremely limited circumstances: when the compiler can track the slice 
> from creation to destruction and when the slice never escapes in any 
> way.  I'm skeptical that such a case happens often enough to be worth 
> implementing. 
>
> (And even if we did implement it we would still have the 
> above-mentioned problem that the allocator doesn't support discarding 
> part of an allocation.) 
>
> 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/b69f101c-0705-466c-96d3-7f1ef0adea74%40googlegroups.com.

Re: [go-nuts] Does reducing capacity of a slice return memory?

[Robert Engels]

You are beginning to touch on why modern compacting collectors are beneficial 
in a large class of applications. Not all application profiles benefit from 
this and it comes at a cost, but it is far simpler than rolling your own. 

> On Jul 19, 2019, at 8:47 PM, Andrey Tcherepanov 
>  wrote:
> 
> Thanks Ian, 
> 
> But just to be clear - I do not want to discard _a part_. I want to discard a 
> _whole big one_, copying a small needed part that is still "alive" aside. 
> Allocator perform it's duties as usual -  allocate a new small array, and 
> discard an old one. It is just that compiler invokes this code on defer it if 
> knows that there is only one reference to the remaining part, and that part 
> is "small"
> 
> A.
> 
>> On Friday, July 19, 2019 at 6:43:41 PM UTC-6, Ian Lance Taylor wrote:
>> On Fri, Jul 19, 2019 at 5:17 PM Andrey Tcherepanov 
>>  wrote: 
>> > 
>> > I understand that it is very easy on application level... if programmer 
>> > even thought about it. But my assumption is that compiler has some sort of 
>> > liveness analysis, and it could be utilized here just to help with 
>> > disposal of a bitten part. 
>> 
>> The kind of liveness analysis done by the compiler is only helpful in 
>> extremely limited circumstances: when the compiler can track the slice 
>> from creation to destruction and when the slice never escapes in any 
>> way.  I'm skeptical that such a case happens often enough to be worth 
>> implementing. 
>> 
>> (And even if we did implement it we would still have the 
>> above-mentioned problem that the allocator doesn't support discarding 
>> part of an allocation.) 
>> 
>> 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/b69f101c-0705-466c-96d3-7f1ef0adea74%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/6EE12265-73A7-4AC7-A475-6D0DA052D303%40ix.netcom.com.

Re: [go-nuts] Build kubernetes with gollvm

[Yuan Ting]

OK, I will check out the reflect2 package and take a look. Thanks a lot for 
your direction!

Best,
Ting

On Friday, July 19, 2019 at 10:30:32 PM UTC+8, Ian Lance Taylor wrote:
>
> On Fri, Jul 19, 2019 at 1:11 AM Yuan Ting > 
> wrote: 
> > 
> >  Sorry to have troubled you again, I found that many famous Go projects 
> also import github.com/modern-go/reflect2 , such as kubernetes and moby. 
> According to the second paragraph in your explanation, these popular 
> projects will also failed in compilation. I think this may be a big 
> challenge for gccgo/gollvm's promotion. 
> > 
> > To solve this compiler-sensitive problem, the way I can come up with is 
> replacing all unsafe mechanisms as mentioned above in reflect2 to safe or 
> standard mechanisms (and may go against the purpose of reflect2). I'm not 
> familiar with runtime, but is it possible to support the same symbol in 
> gccgo/gollvm style? 
>
> Simply supporting runtime.typelinks is not enough.  The reflect 
> package is closely tied to the compiler implementation.  The reflect 
> package is not identical in the gc library and the GoLLVM library.  If 
> people need reflect2 to work with GoLLVM, then the only workable 
> option is for the reflect2 authors to write a version of their package 
> that uses the gccgo build tag to build a version that works with 
> GoLLVM.  Perhaps you could help them with that.  Sorry this isn't very 
> helpful.  I don't really understand why people are using the package. 
>
> 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/1fd95c73-6e30-4089-bad4-b21c261d788a%40googlegroups.com.