[go-nuts] Issue with go-git API

[PK]

I am trying to use this git api(*https://github.com/go-git/go-git*), but 
before that I tried to run the provided example (i.e. cloning the repo by 
golang). So I run the program 
*https://github.com/go-git/go-git/blob/master/_examples/clone/main.go*

So when I run this program I used to get this error:
sample.go:7:2: no required module provides package 
github.com/go-git/go-git/v5: go.mod file not found in current directory or 
any parent directory; see 'go help modules'

sample.go:8:2: no required module provides package 
github.com/go-git/go-git/v5/_examples: go.mod file not found in current 
directory or any parent directory; see 'go help modules'

*Please help me, how I can execute this?*

I am using the following:
Go version: go version go1.18.1 linux/amd64
Platform:  Ubuntu 22.04.1 LTS

-- 
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/353c43c7-99bc-4e85-bf94-a5daff749640n%40googlegroups.com.

Re: [go-nuts] Practical use cases of recover in golang

[Henry]

You may want to make your app more robust by handling panic in the topmost 
layer of your application. With many people working on the code and various 
external dependencies, it is often impractical to ensure none of the code 
panics. This is where recover comes in.

On Monday, October 10, 2022 at 10:20:31 AM UTC+7 kra...@skepticism.us wrote:

> The Elvish shell  uses panic capture to 
> ensure an interactive Elvish shell that paniced is replaced by a recovery 
> shell. While still outputting important information about the panic. See this 
> code 
> .
>  
> In other words, sometimes you want to ensure that a) information about the 
> panic is captured (such as logging the panic via an external service) and 
> b) doing something other than simply terminating. Whether to capture a 
> panic is obviously dependent on the specific situation.
>
> I'll also note that I'm working on a change to the Elvish project that 
> will capture a panic to solve the problem of the builtin "exit" command not 
> triggering deferred behaviors; such as capturing profiling data. See this 
> issue . So that is another, highly 
> context dependent, case where capturing a panic is useful. I've got to say 
> that Go's panic/recover mechanism is a beautiful design.
>
> On Sun, Oct 9, 2022 at 2:17 PM cg-guy  wrote:
>
>> Hi Team,
>>
>> Whatever I have been worked so far with golang,I did not use recover() 
>> function . 
>> Curious to know if anyone using recover in production code and can you 
>> please 
>> the scenarios where it is used. 
>>
>> Thanks
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/00f1a25f-2f95-4ed7-8acd-6510bae85c30n%40googlegroups.com
>>  
>> 
>> .
>>
>
>
> -- 
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/b504af79-8db4-4ab1-9655-b7f34f1526den%40googlegroups.com.

[go-nuts] Re: What is the relationship between go community and goproxy.io

[tapi...@gmail.com]

On Sunday, October 9, 2022 at 11:50:49 PM UTC+8 ljh wrote:

> Hi, community,
>
> I Just saw this site: yunzhanghu.com , is listed as Special Sponsor on 
> goproxy.io homepage.
>
> I'm just curious, is goproxy.io endorsed by The Go Team and is goproxy.io 
> trustworthy? 
>

By the go module cache system design, if you trust the server set in your 
GOSUMDB env var,
which is defaulted to sum.golang.org, then it is not a matter whatever 
proxy server your are using.
 

>
> $ whois goproxy.io
> Registrant Name: REDACTED FOR PRIVACY
>
>

-- 
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/e38557f7-774a-4a36-8d15-5bab40512a51n%40googlegroups.com.

Re: [go-nuts] Practical use cases of recover in golang

[Kurtis Rader]

The Elvish shell  uses panic capture to
ensure an interactive Elvish shell that paniced is replaced by a recovery
shell. While still outputting important information about the panic. See this
code
.
In other words, sometimes you want to ensure that a) information about the
panic is captured (such as logging the panic via an external service) and
b) doing something other than simply terminating. Whether to capture a
panic is obviously dependent on the specific situation.

I'll also note that I'm working on a change to the Elvish project that will
capture a panic to solve the problem of the builtin "exit" command not
triggering deferred behaviors; such as capturing profiling data. See this
issue . So that is another, highly
context dependent, case where capturing a panic is useful. I've got to say
that Go's panic/recover mechanism is a beautiful design.

On Sun, Oct 9, 2022 at 2:17 PM cg-guy  wrote:

> Hi Team,
>
> Whatever I have been worked so far with golang,I did not use recover()
> function .
> Curious to know if anyone using recover in production code and can you
> please
> the scenarios where it is used.
>
> Thanks
>
> --
> 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/00f1a25f-2f95-4ed7-8acd-6510bae85c30n%40googlegroups.com
> 
> .
>


-- 
Kurtis Rader
Caretaker of the exceptional canines Junior and Hank

-- 
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/CABx2%3DD9m0EGmP%2Bya%2BXSRgd92a9yM2b61RV0QbQ31ci11zX9kyA%40mail.gmail.com.

[go-nuts] Re: Practical use cases of recover in golang

[Eswaran S.K.]

Production Code is typically written with multiple layers of abstraction.
Typical patterns involve generic ones like Proxy / Command patterns.

In these types of pattern, execution context is provided by the 
Client/Invoker.
But, the implementation for execution is done by the different abstraction 
object.

Also, in such cases typically there are multiple implementation objects 
that gets executed based on configuration/scenarios that are only decided 
at runtime.

Based on organizational structure and how work gets divided it might be 
built by different teams within or spanning multiple organizations.

In such chases, to gracefully handle and implement the functionality of the 
Client/Invoker, recovering from panic's is important.
I have personally used recover() to gracefully handle scenarios that arose 
from third party libraries.

On Monday, October 10, 2022 at 2:46:52 AM UTC+5:30 cg-guy wrote:

> Hi Team,
>
> Whatever I have been worked so far with golang,I did not use recover() 
> function . 
> Curious to know if anyone using recover in production code and can you 
> please 
> the scenarios where it is used. 
>
> Thanks
>

-- 
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/68757f01-1871-4dee-9245-84a7b44cb5c3n%40googlegroups.com.

Re: [go-nuts] Practical use cases of recover in golang

[Ian Lance Taylor]

On Sun, Oct 9, 2022 at 2:17 PM cg-guy  wrote:
>
> Whatever I have been worked so far with golang,I did not use recover() 
> function .
> Curious to know if anyone using recover in production code and can you please
> the scenarios where it is used.

You may want to look at how it is used in the Go standard library, for
example in the encoding/json 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/CAOyqgcU77Ehe_BRxCxspie0MRn76vpBi_GDgRLVLr01C11cR%3Dw%40mail.gmail.com.

[go-nuts] Practical use cases of recover in golang

[cg-guy]

Hi Team,

Whatever I have been worked so far with golang,I did not use recover() 
function . 
Curious to know if anyone using recover in production code and can you 
please 
the scenarios where it is used. 

Thanks

-- 
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/00f1a25f-2f95-4ed7-8acd-6510bae85c30n%40googlegroups.com.

Re: [go-nuts] Go generics: type constraint for function or (non-type constraint) interface?

[TheDiveO]

Thank you! I was already expecting a twin no, but wanted to ensure that I 
didn't had overlooked something.

On Wednesday, September 28, 2022 at 9:12:16 PM UTC+2 
axel.wa...@googlemail.com wrote:

> No and no.
>
> On Wed, Sep 28, 2022 at 9:05 PM TheDiveO  wrote:
>
>> Is there currently a way in Go generics to express a type constraint to 
>> allow only
>> - any function
>> - any interface that isn't a type constraint, such as ~int
>> ?
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/16b6413d-fd37-4f37-8c42-7665764a465bn%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/34e01742-0324-4d86-9c26-4000a8e876acn%40googlegroups.com.

Re: [go-nuts] What is the relationship between go community and goproxy.io

[Ian Lance Taylor]

On Sun, Oct 9, 2022 at 10:59 AM ljh  wrote:
>
> There is no official proxy / mirror sites by core team, right?

The Go team runs proxy.golang.org.  See
https://go.dev/blog/module-mirror-launch .  The "go" command uses that
proxy by default, though you can change that; see
https://pkg.go.dev/cmd/go#hdr-Modules__module_versions__and_more .

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

Re: [go-nuts] Structures / mutex question

[burak serdar]

On Sun, Oct 9, 2022 at 12:44 PM Slawomir Pryczek 
wrote:

> Thanks, very good point about including the structure by-value.
>
> As for using the structure via pointer
>
> > You don't need to rlock the global mutex. Even if another goroutine
> appends to
> > the slice and slice gets reallocated, this code will still be pointing
> to the correct element.
>
> I'd assume I'll still need the global RLock, as len will not be
> synchronized. And moreover if i shrink the array by 1 and then append one
> element, i'll be changing the pointer in-place which could result in some
> pseudo-random memory location being accessed.
>

If you create a goroutine and work with one of the elements of the slice of
pointers, you will not need to rlock the global mutex. If that goroutine
accesses the slice itself, then yes, you'll need it.


>
> niedziela, 9 października 2022 o 18:38:36 UTC+2 bse...@computer.org
> napisał(a):
>
>> On Sun, Oct 9, 2022 at 5:49 AM Slawomir Pryczek 
>> wrote:
>>
>>> Hi Guys,
>>> wanted to see if i making correct assumptions regarding mutexes and
>>> structures
>>>
>>> var globalMutex sync.Mutex{}
>>> type abc struct {
>>> a int
>>> b int
>>> mu sync.Mutex{}
>>> }
>>>
>>> 1. First is self explanatory, array of structures all needs to be
>>> protected by mutex
>>> x := []abc{}
>>> x = append(x, abc{})  // <- This needs to be done inside globalMutex.Lock
>>>
>>
>> There are some things to consider for this usage. You need the global
>> mutex to lock the slice when appending. If append needs to reallocate a new
>> slice, using a *sync.Mutex will work, but any goroutines working on the
>> elements of the slice will be working on stale copies of it. That is, if
>> one goroutine appends to the slice while another is modifying its elements,
>> the modification to the elements may be lost in the new copy of the slice.
>>
>> In short: you should not use struct abc as value if you're ever going to
>> append to the slice.
>>
>> If you are not going to append, then embed *sync.Mutex, otherwise you
>> will be copying the mutex.
>>
>>
>>> x[0].a = 10 // <- This needs to be done inside globalMutex.Lock, as the
>>> array/slice is holding the data (?)
>>>
>>
>> In general, you can lock x[0] for this without locking the global mutex,
>> so other goroutines can update other elements of the array. This, if only
>> you are not appending to the slice.
>>
>>
>>> - Reading x[0].a would require globalMutex.*RLock*
>>>
>>
>> It would require x[0].RLock(), if you are not appending to the slice.
>>
>>
>>>
>>> - Mu is not necessary
>>>
>>
>> You can do this with a global mutex, but that will prevent concurrency
>> for goroutines working on different slice elements.
>>
>>
>>>
>>> 2. Array of pointer to structures
>>> y := []*abc{}
>>> _tmp := {}
>>> y = append(y, _tmp)   <- This needs to be put inside globalMutex.Lock
>>> Mutex
>>>
>>
>> The above is correct.
>>
>>
>>>  y[0].b = 1  <- This can be put inside  globalMutex.RLock and we also
>>> need mu.Lock (as it's sufficient to read abc pointer and the pointer will
>>> never change after the element gets added to the list)
>>>
>>
>> You don't need to rlock the global mutex. Even if another goroutine
>> appends to the slice and slice gets reallocated, this code will still be
>> pointing to the correct element.
>>
>>
>>> - Reading y[0].b would require RLock on both globalMutex and mu
>>>
>>
>> It would require rlock on y[0] only.
>>
>>
>>>
>>> Or maybe it's better to just use generic read-write locks for everything
>>> and don't bother?
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/ffc7c10e-ddb9-4bc5-a545-2a1ce7b22bfbn%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/4c03668d-58b7-4629-8c27-001473005145n%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 

Re: [go-nuts] Structures / mutex question

[Slawomir Pryczek]

Thanks, very good point about including the structure by-value.

As for using the structure via pointer

> You don't need to rlock the global mutex. Even if another goroutine 
appends to
> the slice and slice gets reallocated, this code will still be pointing to 
the correct element.

I'd assume I'll still need the global RLock, as len will not be 
synchronized. And moreover if i shrink the array by 1 and then append one 
element, i'll be changing the pointer in-place which could result in some 
pseudo-random memory location being accessed.

niedziela, 9 października 2022 o 18:38:36 UTC+2 bse...@computer.org 
napisał(a):

> On Sun, Oct 9, 2022 at 5:49 AM Slawomir Pryczek  
> wrote:
>
>> Hi Guys,
>> wanted to see if i making correct assumptions regarding mutexes and 
>> structures
>>
>> var globalMutex sync.Mutex{}
>> type abc struct {
>> a int
>> b int
>> mu sync.Mutex{}
>> }
>>
>> 1. First is self explanatory, array of structures all needs to be 
>> protected by mutex
>> x := []abc{}
>> x = append(x, abc{})  // <- This needs to be done inside globalMutex.Lock
>>
>
> There are some things to consider for this usage. You need the global 
> mutex to lock the slice when appending. If append needs to reallocate a new 
> slice, using a *sync.Mutex will work, but any goroutines working on the 
> elements of the slice will be working on stale copies of it. That is, if 
> one goroutine appends to the slice while another is modifying its elements, 
> the modification to the elements may be lost in the new copy of the slice.
>
> In short: you should not use struct abc as value if you're ever going to 
> append to the slice.
>
> If you are not going to append, then embed *sync.Mutex, otherwise you will 
> be copying the mutex.
>  
>
>> x[0].a = 10 // <- This needs to be done inside globalMutex.Lock, as the 
>> array/slice is holding the data (?)
>>
>
> In general, you can lock x[0] for this without locking the global mutex, 
> so other goroutines can update other elements of the array. This, if only 
> you are not appending to the slice.
>  
>
>> - Reading x[0].a would require globalMutex.*RLock*
>>
>
> It would require x[0].RLock(), if you are not appending to the slice.
>  
>
>>
>> - Mu is not necessary
>>
>
> You can do this with a global mutex, but that will prevent concurrency for 
> goroutines working on different slice elements.
>  
>
>>
>> 2. Array of pointer to structures
>> y := []*abc{}
>> _tmp := {}
>> y = append(y, _tmp)   <- This needs to be put inside globalMutex.Lock 
>> Mutex
>>
>
> The above is correct.
>  
>
>>  y[0].b = 1  <- This can be put inside  globalMutex.RLock and we also 
>> need mu.Lock (as it's sufficient to read abc pointer and the pointer will 
>> never change after the element gets added to the list)
>>
>
> You don't need to rlock the global mutex. Even if another goroutine 
> appends to the slice and slice gets reallocated, this code will still be 
> pointing to the correct element.
>  
>
>> - Reading y[0].b would require RLock on both globalMutex and mu
>>
>
> It would require rlock on y[0] only.
>  
>
>>
>> Or maybe it's better to just use generic read-write locks for everything 
>> and don't bother?
>>
>> Thanks
>>
>>
>>
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/ffc7c10e-ddb9-4bc5-a545-2a1ce7b22bfbn%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/4c03668d-58b7-4629-8c27-001473005145n%40googlegroups.com.

回复： [go-nuts] What is the relationship between go community and goproxy.io

['ljh' via golang-nuts]

Thanks Ian,


There is no official proxy / mirror sites by core team, 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/tencent_4787E4F3F3827D302E8D0D2781F2E6628909%40qq.com.

Re: [go-nuts] Structures / mutex question

[burak serdar]

On Sun, Oct 9, 2022 at 5:49 AM Slawomir Pryczek 
wrote:

> Hi Guys,
> wanted to see if i making correct assumptions regarding mutexes and
> structures
>
> var globalMutex sync.Mutex{}
> type abc struct {
> a int
> b int
> mu sync.Mutex{}
> }
>
> 1. First is self explanatory, array of structures all needs to be
> protected by mutex
> x := []abc{}
> x = append(x, abc{})  // <- This needs to be done inside globalMutex.Lock
>

There are some things to consider for this usage. You need the global mutex
to lock the slice when appending. If append needs to reallocate a new
slice, using a *sync.Mutex will work, but any goroutines working on the
elements of the slice will be working on stale copies of it. That is, if
one goroutine appends to the slice while another is modifying its elements,
the modification to the elements may be lost in the new copy of the slice.

In short: you should not use struct abc as value if you're ever going to
append to the slice.

If you are not going to append, then embed *sync.Mutex, otherwise you will
be copying the mutex.


> x[0].a = 10 // <- This needs to be done inside globalMutex.Lock, as the
> array/slice is holding the data (?)
>

In general, you can lock x[0] for this without locking the global mutex, so
other goroutines can update other elements of the array. This, if only you
are not appending to the slice.


> - Reading x[0].a would require globalMutex.*RLock*
>

It would require x[0].RLock(), if you are not appending to the slice.


>
> - Mu is not necessary
>

You can do this with a global mutex, but that will prevent concurrency for
goroutines working on different slice elements.


>
> 2. Array of pointer to structures
> y := []*abc{}
> _tmp := {}
> y = append(y, _tmp)   <- This needs to be put inside globalMutex.Lock Mutex
>

The above is correct.


>  y[0].b = 1  <- This can be put inside  globalMutex.RLock and we also need
> mu.Lock (as it's sufficient to read abc pointer and the pointer will never
> change after the element gets added to the list)
>

You don't need to rlock the global mutex. Even if another goroutine appends
to the slice and slice gets reallocated, this code will still be pointing
to the correct element.


> - Reading y[0].b would require RLock on both globalMutex and mu
>

It would require rlock on y[0] only.


>
> Or maybe it's better to just use generic read-write locks for everything
> and don't bother?
>
> Thanks
>
>
>
>
>
>
> --
> 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/ffc7c10e-ddb9-4bc5-a545-2a1ce7b22bfbn%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/CAMV2RqpX7vS3MCWP0mUG%2Bi6UobH-frHnOY4uG8tnnL3C8pBdGg%40mail.gmail.com.

Re: [go-nuts] What is the relationship between go community and goproxy.io

[Ian Lance Taylor]

On Sun, Oct 9, 2022, 10:50 AM 'ljh' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Hi, community,
>
> I Just saw this site: yunzhanghu.com , is listed as Special Sponsor on
> goproxy.io homepage.
>
> I'm just curious, is goproxy.io endorsed by The Go Team and is goproxy.io
> trustworthy?
>
> $ whois goproxy.io
> Registrant Name: REDACTED FOR PRIVACY
>

goproxy.io is not run by, or endorsed by, the core Go team.

That said, it's been around for a while, and I've never heard anything bad
about it.  But I've never used it myself.

Ian

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

[go-nuts] get function body comments using ast

[Dmitry Belyaev]

Hey fellow gophers,

I am trying to get comments from inside of function declaration while also 
accessing function name, but haven't had much success. Getting name and doc 
is quite straightforward, I do it with:

fset := token.NewFileSet()

f, _ := parser.ParseFile(fset, "testfile", nil, parser.ParseComments)

ast.Inspect(f, func(n ast.Node) bool {
fn, ok := n.(*ast.FuncDecl)
if ok {
fmt.Println(fn.Name.String(), fn.Doc.Text())
}
 }

For a function like below I'd get only *example // doc comment*,

// doc comment
func example() {
  // body comment   < looking to extract this comment
}

but I am looking also to extract *// body comment*.

Please advise on how to extract function name, doc comment AND body comment 
altogether. 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/cad2e200-fb20-4b3c-b143-c3eb858323d4n%40googlegroups.com.

[go-nuts] What is the relationship between go community and goproxy.io

['ljh' via golang-nuts]

Hi, community,


I Just saw this site: yunzhanghu.com , is listed as Special Sponsor on 
goproxy.io homepage.


I'm just curious, is goproxy.io endorsed by The Go Team and is goproxy.io 
trustworthy?


$ whois goproxy.io
Registrant Name: REDACTED FOR PRIVACY

-- 
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/tencent_95B821E77C96E0148C4DE3C3C991BC825807%40qq.com.

[go-nuts] Re:What is the relationship between go community and goproxy.io

['ljh' via golang-nuts]

Just found another, are these two sites related: 
goproxy.io,goproxy.cn .

-- 
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/tencent_8787A6F2D18287310C8D95262FF226622F09%40qq.com.

[go-nuts] Structures / mutex question

[Slawomir Pryczek]

Hi Guys,
wanted to see if i making correct assumptions regarding mutexes and 
structures

var globalMutex sync.Mutex{}
type abc struct {
a int
b int
mu sync.Mutex{}
}

1. First is self explanatory, array of structures all needs to be protected 
by mutex
x := []abc{}
x = append(x, abc{})  // <- This needs to be done inside globalMutex.Lock
x[0].a = 10 // <- This needs to be done inside globalMutex.Lock, as the 
array/slice is holding the data (?)
- Reading x[0].a would require globalMutex.*RLock*
- Mu is not necessary

2. Array of pointer to structures
y := []*abc{}
_tmp := {}
y = append(y, _tmp)   <- This needs to be put inside globalMutex.Lock Mutex
 y[0].b = 1  <- This can be put inside  globalMutex.RLock and we also need 
mu.Lock (as it's sufficient to read abc pointer and the pointer will never 
change after the element gets added to the list)
- Reading y[0].b would require RLock on both globalMutex and mu

Or maybe it's better to just use generic read-write locks for everything 
and don't bother?

Thanks






-- 
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/ffc7c10e-ddb9-4bc5-a545-2a1ce7b22bfbn%40googlegroups.com.