Re: [go-nuts] using or extending or forking+renaming github.com/google/licensecheck to provide similar functionality

[fgergo]

func Cover(input []byte, opts Options) (Coverage, bool) in
licensecheck currently reports len(input)/len(one of the licenses) for
each known license. I'd need for all known licenses len(known
license)/len(license reference in input).

I'd like to scan >10 files (possibly a lot more), where some of
them (<0.1%) contain full or partial known license texts.

An example scenario for an example /src, containing >10 files:
$ listlicenses /src # to get an overview of 100% matching license references
LGPL-2.1
MIT
$ listlicenses -details /src# same tree, more detailed output, to
see the details
/src/license refers 100% MIT   # the bytes in /src/license correspond
one for one for the MIT license
/src/fonts/LICENSE refers 100% MIT   # the bytes in /src/fonts/LICENSE
correspond one for one for the MIT license
/src/a/Notice refers 100% LGPL-2.1   # same as above with LGPL-2.1
/src/a/b/whatever.go refers 94% GPL2   # most probably a broken
license reference in whatever.go, maybe someone inadvertently deleted
the last word from the lines containing the GPL2 license text. Needs
human inspection to check what's the license situation with
whatever.go
/src/c/ConfusingLicenseReferences.c refers 7% ZLIB   #
ConfusingLicenseReferences.c has most probably a false positive report
for reference to ZLIB
/src/c/ConfusingLicenseReferences.c refers 65% MIT#
ConfusingLicenseReferences.c has only 65% of MIT, the author intended
to refer to MIT, but some inadvertent edit later broke the license
reference in ConfusingLicenseReferences.c

Command listlicenses iterates over all files in the subtree, gathering
all full or partial (broken) license references. Command listlicenses
uses the functionality similar to github.com/google/licensecheck to
check the files in the file system.



thanks!

On 11/13/19, Rob Pike  wrote:
> Can you please explain in more detail what you're asking for? I don't
> understand the problem you have or why the current package cannot handle
> it.
>
> -rob
>
>
> On Wed, Nov 13, 2019 at 7:05 PM  wrote:
>
>> Hi,
>>
>>  "licensecheck classifies license files and heuristically determines
>> how well they correspond to known open source licenses."
>>
>> I'd like to identify license references in the file system. If I
>> understand correctly package licensecheck in it's current form is not
>> useful to help with this.
>> If it's still possible, could you please share a hint how to do that?
>> (input: byte array, output: license references in the byte array)
>> If I understand correctly and I can't use licensecheck in it's current
>> form, which one is preferred:
>> extend current api, (maybe: func Refers(input []byte) (References,
>> bool) or fork+rename the package? (References{...} being similar to
>> Coverage{...})
>>
>> thanks,
>> Gergely Födémesi
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2BctqrqKKUPTHihMLhLTH5O-tBm1qENQV6y41Qwde4jHp1kNmA%40mail.gmail.com
>> .
>>
>

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

Re: [go-nuts] go.dev is live!

[Dan Kortschak]

Also, the license feedback link at https://pkg.go.dev/license-policy
fails to work on Firefox.

On Thu, 2019-11-14 at 15:24 +1030, Dan Kortschak wrote:
> Hi,
> 
> It looks like license detection needs work.
> 
> See https://pkg.go.dev/gonum.org/v1/gonum?tab=overview and note it
> has
> a BSD 3 clause, as shown by GitHub's assessment (just above the
> "Clone
> or download" button) at https://github.com/gonum/gonum and the
> LICENSE
> file that it links to.
> 
> Dan
> 
> On Wed, 2019-11-13 at 12:12 -0500, 'Julie Qiu' via golang-dev wrote:
> > Hey Gophers,
> > 
> > We are excited to share that go.dev, a new hub for Go developers,
> > is
> > now
> > live!
> > 
> > At go.dev, you will find information on how to get started with the
> > language, featured use cases, and other resources. It is a
> > companion
> > site
> > to golang.org. You can read about it on the latest Go blog post
> > .
> > 
> > You will also find a new place to discover Go packages and modules,
> > pkg.go.dev, by clicking on Explore in the header or footer.
> > 
> > Pkg.go.dev  serves Go documentation like
> > godoc.org, but
> > it also understands modules and has information about previous
> > versions of
> > a package (such as all releases of the Go standard library
> > !). It also detects and
> > displays
> > licenses and has a better search algorithm.
> > 
> > You can follow Go issue 33654  for
> > future
> > developments on pkg.go.dev.
> > 
> > We are just starting to build out go.dev, so some bugs are to be
> > expected.
> > We want to work with all of you to make this site better for Go
> > developers,
> > so please share your feedback with us and file issues if you spot
> > them! You
> > can do that by clicking "Share Feedback" or "Report an Issue" at
> > the
> > footer
> > of every page, or by emailing go-discovery-feedb...@google.com. See
> > go.dev/about for more information about the site.
> > 
> > We hope you enjoy the new site and look forward to hearing your
> > feedback!
> > 
> > Warmly ☀️,
> > 
> > Julie for the Go team
> > 
> 
> 

-- 
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/af536470592ab712900a0cdd42e25cc9bbee4f1c.camel%40kortschak.io.

[go-nuts] Re: [golang-dev] go.dev is live!

[Dan Kortschak]

Hi,

It looks like license detection needs work.

See https://pkg.go.dev/gonum.org/v1/gonum?tab=overview and note it has
a BSD 3 clause, as shown by GitHub's assessment (just above the "Clone
or download" button) at https://github.com/gonum/gonum and the LICENSE
file that it links to.

Dan

On Wed, 2019-11-13 at 12:12 -0500, 'Julie Qiu' via golang-dev wrote:
> Hey Gophers,
> 
> We are excited to share that go.dev, a new hub for Go developers, is
> now
> live!
> 
> At go.dev, you will find information on how to get started with the
> language, featured use cases, and other resources. It is a companion
> site
> to golang.org. You can read about it on the latest Go blog post
> .
> 
> You will also find a new place to discover Go packages and modules,
> pkg.go.dev, by clicking on Explore in the header or footer.
> 
> Pkg.go.dev  serves Go documentation like
> godoc.org, but
> it also understands modules and has information about previous
> versions of
> a package (such as all releases of the Go standard library
> !). It also detects and displays
> licenses and has a better search algorithm.
> 
> You can follow Go issue 33654  for
> future
> developments on pkg.go.dev.
> 
> We are just starting to build out go.dev, so some bugs are to be
> expected.
> We want to work with all of you to make this site better for Go
> developers,
> so please share your feedback with us and file issues if you spot
> them! You
> can do that by clicking "Share Feedback" or "Report an Issue" at the
> footer
> of every page, or by emailing go-discovery-feedb...@google.com. See
> go.dev/about for more information about the site.
> 
> We hope you enjoy the new site and look forward to hearing your
> feedback!
> 
> Warmly ☀️,
> 
> Julie for the Go team
> 

-- 
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/bf80461f5333dd072402d1d5bd13b21dbf6276c2.camel%40kortschak.io.

[go-nuts] Re: [golang-dev] go.dev is live!

[Tyler Compton]

Thanks for posting! I'm really impressed the website, and with the package
view especially. I foresee myself using this instead of godoc.org from now
on.

I'm curious to hear more about the team's future plans for golang.org. Do
you have any plans to migrate or mirror content like the blog or the
download links over time? I could see some minor confusion popping up
regarding which website to go to for which task, though I see this has been
partially addressed by adding links to many of golang.org's resources on
go.dev, which is thoughtful.

On Wed, Nov 13, 2019, 09:15 'Julie Qiu' via golang-dev <
golang-...@googlegroups.com> wrote:

> Hey Gophers,
>
> We are excited to share that go.dev, a new hub for Go developers, is now
> live!
>
> At go.dev, you will find information on how to get started with the
> language, featured use cases, and other resources. It is a companion site
> to golang.org. You can read about it on the latest Go blog post
> .
>
> You will also find a new place to discover Go packages and modules,
> pkg.go.dev, by clicking on Explore in the header or footer.
>
> Pkg.go.dev  serves Go documentation like godoc.org,
> but it also understands modules and has information about previous versions
> of a package (such as all releases of the Go standard library
> !). It also detects and displays
> licenses and has a better search algorithm.
>
> You can follow Go issue 33654  for future
> developments on pkg.go.dev.
>
> We are just starting to build out go.dev, so some bugs are to be
> expected. We want to work with all of you to make this site better for Go
> developers, so please share your feedback with us and file issues if you
> spot them! You can do that by clicking "Share Feedback" or "Report an
> Issue" at the footer of every page, or by emailing
> go-discovery-feedb...@google.com. See go.dev/about for more information
> about the site.
>
> We hope you enjoy the new site and look forward to hearing your feedback!
>
> Warmly ☀️,
>
> Julie for the Go team
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-dev/CAGJ2NqEcskx_492HFpV%3DUavMLgXoYmXaZ1ivigqnjfc-9U8wFA%40mail.gmail.com
> 
> .
>

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

[go-nuts] Question: package rename

[awh6al]

Hi gophers, i have a question about renaming a package like 
`debug/plan9obj` to `p9` with a required changes in the package files. I 
got a `can't load package` message from `go test -v debug/p9` command, any 
ideas?

-- 
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/748d0a22-f441-4373-9559-b4cdf1335c8f%40googlegroups.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Serge Hulne]

Thank you!


On Wed 13 Nov 2019 at 21:08, Russel Winder  wrote:

> On Wed, 2019-11-13 at 06:02 -0800, Serge Hulne wrote:
> > Am I therefore correct in assuming that, if the problem I am trying to
> model
> > is not IO bound or CPU bound, but deals essentially with modeling a large
> > number of independent cells (a sort of massively parallel « Game of life
> »),
> > where each cells lives in its own process, it makes more sense to model
> it
> > in Golang rather than rust?
>
> No. At least not per se.
>
> If you feel more comfortable doing it in Go in preference to Rust that
> choose
> Go. Another person might have a different background and therefore choose
> Rust. The programming languages do not provide the disambiguation, it is
> about
> the programmer(s), the audience, and the context.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>
>

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

Re: [go-nuts] Should I return an error object, or a pointer to an error object?

[Brian Candler]

Thanks.  It's much clearer now.

Cheers,

Brian.

-- 
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/d3227e25-50a6-499b-9150-8be9196462f9%40googlegroups.com.

Re: [go-nuts] Should I return an error object, or a pointer to an error object?

[Ian Lance Taylor]

On Wed, Nov 13, 2019 at 12:23 PM Brian Candler  wrote:
>
> > the current implementation of interfaces is that they always store pointer
> > values.  If you store a non-pointer value in an interface, that value
> > is copied into memory, and a pointer to that memory is stored in the
> > interface.
>
> I don't understand where you say "that value is copied into memory".  If 
> we're talking about a value that already exists, surely it just obtains a 
> pointer to it, without any copying?
>
> In other words: if you return a pointer value, then to convert it to an 
> interface type it has to box it as [*T, ptr].  If you return a concrete 
> object, then it has to take a pointer to that object, and box it as [T, ptr].

At the level at which we are talking, a value will typically be on the
stack or in registers, but a value converted to an interface type will
typically be on the heap.  So that is the copy to which I referred:
from the stack to the heap.  There are various exceptions and
conditions, but that is the most common case.


> To my mind, the advantage of a concrete object is that it cannot be nil; if 
> it's used as an interface value, there's only one possible way it can be nil. 
> If you return a pointer to satisfy an interface then there are two ways it 
> can be nil: a nil interface value, and a non-nil interface value containing a 
> nil *T value.  It was a big source of confusion to me initially :-)
>
> Still... if returning a pointer to an error is The Go Way, I guess I'll do 
> that.  It would be nice if the documentation was more explicit about this.

I don't mean to say that it is The Go Way.  I was only trying to
provide a plausible reason why the code in the blog post was written
that way.  It would be absolutely fine to use a value rather than a
pointer; that would be just as much The Go Way.

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

Re: [go-nuts] using or extending or forking+renaming github.com/google/licensecheck to provide similar functionality

[Rob Pike]

Can you please explain in more detail what you're asking for? I don't
understand the problem you have or why the current package cannot handle it.

-rob


On Wed, Nov 13, 2019 at 7:05 PM  wrote:

> Hi,
>
>  "licensecheck classifies license files and heuristically determines
> how well they correspond to known open source licenses."
>
> I'd like to identify license references in the file system. If I
> understand correctly package licensecheck in it's current form is not
> useful to help with this.
> If it's still possible, could you please share a hint how to do that?
> (input: byte array, output: license references in the byte array)
> If I understand correctly and I can't use licensecheck in it's current
> form, which one is preferred:
> extend current api, (maybe: func Refers(input []byte) (References,
> bool) or fork+rename the package? (References{...} being similar to
> Coverage{...})
>
> thanks,
> Gergely Födémesi
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CA%2BctqrqKKUPTHihMLhLTH5O-tBm1qENQV6y41Qwde4jHp1kNmA%40mail.gmail.com
> .
>

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

Re: [go-nuts] Should I return an error object, or a pointer to an error object?

[Brian Candler]

> the current implementation of interfaces is that they always store pointer
> values.  If you store a non-pointer value in an interface, that value
> is copied into memory, and a pointer to that memory is stored in the
> interface.

I don't understand where you say "that value is copied into memory".  If 
we're talking about a value that already exists, surely it just obtains a 
pointer to it, without any copying?

In other words: if you return a pointer value, then to convert it to an 
interface type it has to box it as [*T, ptr].  If you return a concrete 
object, then it has to take a pointer to that object, and box it as [T, 
ptr].

To my mind, the advantage of a concrete object is that it cannot be nil; if 
it's used as an interface value, there's only one possible way it can be 
nil. If you return a pointer to satisfy an interface then there are two 
ways it can be nil: a nil interface value, and a non-nil interface value 
containing a nil *T value.  It was a big source of confusion to me 
initially :-)

Still... if returning a pointer to an error is The Go Way, I guess I'll do 
that.  It would be nice if the documentation was more explicit about this.

Cheers,

Brian.

-- 
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/b6efcb16-0cf6-42f0-b796-0c027c227d77%40googlegroups.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Russel Winder]

On Wed, 2019-11-13 at 06:02 -0800, Serge Hulne wrote:
> Am I therefore correct in assuming that, if the problem I am trying to model
> is not IO bound or CPU bound, but deals essentially with modeling a large
> number of independent cells (a sort of massively parallel « Game of life »),
> where each cells lives in its own process, it makes more sense to model it
> in Golang rather than rust?

No. At least not per se.

If you feel more comfortable doing it in Go in preference to Rust that choose
Go. Another person might have a different background and therefore choose
Rust. The programming languages do not provide the disambiguation, it is about
the programmer(s), the audience, and the context.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-- 
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/02c2a2f7926e5fa54c16f135ecc84230ef102862.camel%40winder.org.uk.


signature.asc
Description: This is a digitally signed message part

[go-nuts] Re: Please make a benchmark of my database on your PC

[Claygod]

 

My new result


goos: linux

goarch: amd64

pkg: github.com/claygod/coffer

BenchmarkClean-8 10 0.00311 ns/op

BenchmarkCofferWriteParallel32NotConcurent-8 
time="2019-11-13T22:00:13+03:00" level=error msg="open 
./test/100031.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:13+03:00" level=error msg="open 
./test/100032.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:13+03:00" level=error msg="open 
./test/100037.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:13+03:00" level=error msg="open 
./test/100037.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:13+03:00" level=error msg="Key length 5 is greater 
than permissible 4Method=workerFollow interactor is STOPPED!" 
Object=FollowInteractor

time="2019-11-13T22:00:14+03:00" level=error msg="open 
./test/100039.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:14+03:00" level=error msg="open 
./test/100042.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:14+03:00" level=error msg="open 
./test/100043.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

time="2019-11-13T22:00:14+03:00" level=error msg="open 
./test/100049.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

205120 17052 ns/op

BenchmarkCofferWriteParallel32HiConcurent-8 
time="2019-11-13T22:00:15+03:00" level=error msg="open 
./test/100055.log: no such file or directoryMethod=workerFollow 
interactor is STOPPED!" Object=FollowInteractor

194988 6016 ns/op

BenchmarkCofferTransactionSequence-8 5328 226378 ns/op

BenchmarkCofferTransactionPar32NotConcurent-8 289456 3876 ns/op

BenchmarkCofferTransactionPar32HalfConcurent-8 283200 3946 ns/op

-- 
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/7f69a84d-f11d-4067-90e4-450dccb7bb03%40googlegroups.com.

Re: [go-nuts] pprof cpu profile doesn't write sample to file

[Ian Lance Taylor]

On Wed, Nov 13, 2019 at 9:37 AM bln prasad  wrote:
>
> I'm running go application as systemd service. I've enabled cpu profile using 
> pprof as specified in documents. When service ran, it's creating file but no 
> samples are getting written to file.
> Does it required any special build arguments?
>
>f, err := os.Create("/tmp/cpu.prof")
> if err != nil {
> log.Fatal("could not create CPU profile: ", err)
> }
> defer f.Close()
>
> if err := pprof.StartCPUProfile(f); err != nil {
> log.Fatal("could not start CPU profile: ", err)
> }
> defer pprof.StopCPUProfile()

It's impossible to tell without seeing more of your program.  The
program has to actually do something between the calls to
StartCPUProfile and StopCPUProfile.  In particular, samples are taken
by default every 10 milliseconds, so if your program runs for a much
shorter amount of time then it would be normal to not see any samples.

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/CAOyqgcVaquW%2Bv6W26fPmdtoD9xZyhF9D4yOU6c08J%3D4tjT6a-w%40mail.gmail.com.

Re: [go-nuts] Should I return an error object, or a pointer to an error object?

[Ian Lance Taylor]

On Wed, Nov 13, 2019 at 9:24 AM Brian Candler  wrote:
>
> In https://blog.golang.org/error-handling-and-go, it shows the well-known 
> error interface:
>
> type error interface {
> Error() string
> }
>
> and it gives an example of a user-defined error:
>
> // errorString is a trivial implementation of error.
> type errorString struct {
> s string
> }
>
> func (e *errorString) Error() string {
> return e.s
> }
>
> // New returns an error that formats as the given text.
> func New(text string) error {
> return {text}
> }
>
> I notice that it's returning a pointer to an error object.  My question is: 
> is there a particular reason for returning a pointer here, rather than a 
> direct instance of an error?
>
> The word "pointer" doesn't appear anywhere in that blog posting.  Clearly a 
> pointer allows the possibility of returning "nil" - but an interface variable 
> can have a nil value too. Without the pointers, it becomes:
>
> func (e errorString) Error() string {
> return e.s
> }
>
> func New(text string) error {
> return errorString{text}
> }
>
> and this appears to work the same - see a longer example on play (based on 
> someone else's example, but I just removed the pointers).
>
> I'm aware that the method set of *T includes the methods of T, so a pointer 
> functions perfectly well in place of a concrete value to implement an 
> interface.  Also, passing a pointer might be slightly more efficient, in that 
> it reduces a bit of copying.  Other than that, is there a reason why code 
> should return pointers to error objects rather than error objects?
>
> I did try looking through the FAQ, which asks "Should I define methods on 
> values or pointers?" (although not "should I return values or pointers?"), 
> and ends up by saying:
>
> For types such as basic types, slices, and small structs, a value receiver is 
> very cheap so unless the semantics of the method requires a pointer, a value 
> receiver is efficient and clear.
>
> Which makes me wonder if I'm missing some other reason for using pointers in 
> this context.

That code could have used a value rather than a pointer.

I didn't write it, but I would guess at two possible reasons for using
a pointer.

First, in practice most interfaces are used to hold pointer values.
This is not quite the same as whether a method should be defined on a
(non-pointer) value or a pointer.  The question here is whether, when
converting a value to an interface type, one should convert a
(non-pointer) value or a pointer.  In practice most people use
pointers.  Not because non-pointer values don't work, but just because
it's a common style.

Second, and perhaps the reason the style has developed this way, the
current implementation of interfaces is that they always store pointer
values.  If you store a non-pointer value in an interface, that value
is copied into memory, and a pointer to that memory is stored in the
interface.  So in effect storing a pointer value writes out what the
implementation is doing anyhow.  And then when you call a method, the
code is a tiny bit more efficient if it's a pointer method, since you
can just pass the pointer from the interface rather than copying the
value.  These aren't particularly good reasons, since the efficiency
cost is likely unmeasurable outside of micro-benchmarks, but they
probably feed into the general style.

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

[go-nuts] pprof cpu profile doesn't write sample to file

[bln prasad]

I'm running go application as systemd service. I've enabled cpu profile 
using pprof as specified in documents. When service ran, it's creating file 
but no samples are getting written to file.
Does it required any special build arguments?

   f, err := os.Create("/tmp/cpu.prof")
if err != nil {
log.Fatal("could not create CPU profile: ", err)
}
defer f.Close()

if err := pprof.StartCPUProfile(f); err != nil {
log.Fatal("could not start CPU profile: ", err)
}
defer pprof.StopCPUProfile()

Thanks,
BLN

-- 
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/badd02b7-7880-4ce4-a723-654abcd8adfa%40googlegroups.com.

[go-nuts] Should I return an error object, or a pointer to an error object?

[Brian Candler]

In https://blog.golang.org/error-handling-and-go, it shows the well-known 
error interface:

type error interface {
Error() string
}

and it gives an example of a user-defined error:

// errorString is a trivial implementation of error.
type errorString struct {
s string
}

func (e *errorString) Error() string {
return e.s
}

// New returns an error that formats as the given text.
func New(text string) error {
return {text}
}

I notice that it's returning a *pointer* to an error object.  My question 
is: is there a particular reason for returning a pointer here, rather than 
a direct instance of an error?

The word "pointer" doesn't appear anywhere in that blog posting.  Clearly a 
pointer allows the possibility of returning "nil" - but an interface 
variable can have a nil value  too. 
Without the pointers, it becomes:

func (e errorString) Error() string {
return e.s
}

func New(text string) error {
return errorString{text}
}

and this appears to work the same - see a longer example on play 
 (based on someone else's example, 
but I just removed the pointers).

I'm aware that the method set of *T includes the methods of T, so a pointer 
functions perfectly well in place of a concrete value to implement an 
interface.  Also, passing a pointer might be slightly more efficient, in 
that it reduces a bit of copying.  Other than that, is there a reason why 
code should return pointers to error objects rather than error objects?

I did try looking through the FAQ, which asks "Should I define methods on 
values or pointers? 
" (although not 
"should I return values or pointers?"), and ends up by saying:


*For types such as basic types, slices, and small structs, a value receiver 
is very cheap so unless the semantics of the method requires a pointer, a 
value receiver is efficient and clear.*

Which makes me wonder if I'm missing some other reason for using pointers 
in this context.

Many thanks,

Brian.

-- 
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/b7bed7ae-60f9-427f-b7a4-e317520a894f%40googlegroups.com.

[go-nuts] go.dev is live!

['Julie Qiu' via golang-nuts]

Hey Gophers,

We are excited to share that go.dev, a new hub for Go developers, is now
live!

At go.dev, you will find information on how to get started with the
language, featured use cases, and other resources. It is a companion site
to golang.org. You can read about it on the latest Go blog post
.

You will also find a new place to discover Go packages and modules,
pkg.go.dev, by clicking on Explore in the header or footer.

Pkg.go.dev  serves Go documentation like godoc.org, but
it also understands modules and has information about previous versions of
a package (such as all releases of the Go standard library
!). It also detects and displays
licenses and has a better search algorithm.

You can follow Go issue 33654  for future
developments on pkg.go.dev.

We are just starting to build out go.dev, so some bugs are to be expected.
We want to work with all of you to make this site better for Go developers,
so please share your feedback with us and file issues if you spot them! You
can do that by clicking "Share Feedback" or "Report an Issue" at the footer
of every page, or by emailing go-discovery-feedb...@google.com. See
go.dev/about for more information about the site.

We hope you enjoy the new site and look forward to hearing your feedback!

Warmly ☀️,

Julie for the Go team

-- 
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/CAGJ2NqEcskx_492HFpV%3DUavMLgXoYmXaZ1ivigqnjfc-9U8wFA%40mail.gmail.com.

Re: [go-nuts] Re: What is the correct way to access/modify slice elements concurrently

[Marvin Renich]

* burak serdar  [191112 12:45]:
> Is there a guarantee that the compiler will not reorganize
> instructions around an atomic read/write? That is:
> 
> i++
> k:=atomic.AddInt32(,1)
> 
> Is there a guarantee that the compiler won't rewrite this as:
> 
> k:=atomic.AddInt32(,1)
> i++

First, from one of the issues to which Robert Engels pointed, it appears
that the language designers are in agreement that if atomics are not
covered by the Go Memory Model, they should be.  From this, it seems
safe to me to treat them as if they provide a
does-not-happen-concurrently promise.

>From that (and, independently, from the fact that atomics would
otherwise lose all their documented usefulness) it follows that you have
the same guarantee about reordering that you would have if you replaced
the atomic access with a mutex or channel operation.  Everybody seems to
agree that the compiler can only reorder if such reordering not only
does not affect the behavior of the goroutine being reordered, but also
does not affect the behavior observed by other goroutines _where a
happens-before relationship between those goroutines_ promises such
behavior.

Unfortunately, I cannot find any wording in the GMM that prevents
reordering one goroutine when such reordering breaks a transitive
happens-before relationship with an operation in another goroutine.

The permission to reorder one goroutine is given before the term
"happens before" is defined.  The GMM makes specific guarantees about
the non-transitive happens-before relationships between goroutines, and
gives examples that clearly demonstrate transitive intent, but that
transitive property is never explicitly stated.

In other words, the permission to reorder within one goroutine is never
limited to reordering happens-before operations that do not involve
other goroutines.

I believe this is a much more egregious omission in the GMM than not
mentioning atomics.  It is clearly intended, otherwise the whole GMM is
completely useless.

...Marvin

-- 
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/20191113162815.pjh4mrgvaae64xhq%40basil.wdw.

Re: [go-nuts] Go gouroutines vs Rust threads

[Brian Hatfield]

Note: rust also recently landed async/await:
https://blog.rust-lang.org/2019/11/07/Async-await-stable.html, though I
have not looked into how it schedules the futures (ie, is it a one-cpu loop
like swift or node, does it attempt to schedule futures in an M:N
fashion like goroutines, etc). It's a recent development that seems
excellent for the Rust ecosystem, so it might be looking at further when
learning about language concurrency models.

On Wed, Nov 13, 2019 at 9:22 AM Serge Hulne  wrote:

> Thank you very much for your answers, they are very much appreciated.
>
> Serge.
>
> --
> 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/bbe52ea5-b65b-4959-89cc-80e747322be9%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/CANGiwgbcDxTD0JdqKWfj5W4vR-as8-4Hinr9SmBTDe0gpc%3DP-Q%40mail.gmail.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Serge Hulne]

Thank you very much for your answers, they are very much appreciated.

Serge.

-- 
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/bbe52ea5-b65b-4959-89cc-80e747322be9%40googlegroups.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Robert Engels]

Also, I find the GC model of Go far simpler that the “borrower” model in Rust - 
but to each their own.

I think the “experts” would say use Rust if it is mission critical or needs to 
meet absolute performance metrics. 



> On Nov 13, 2019, at 8:13 AM, Robert Engels  wrote:
> 

-- 
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/FFDC6751-5A87-4127-A4F4-9F9397C4B557%40ix.netcom.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Robert Engels]

It may be easier - as you can code it in a more procedural fashion, but you can 
do it in either system - there are many techniques you can use. 

There are also “green threads” libraries (crates) available for Rust. These may 
over more control over the internal scheduler as well. 

> On Nov 13, 2019, at 8:02 AM, Serge Hulne  wrote:
> 
> Am I therefore correct in assuming that, if the problem I am trying to model 
> is not IO bound or CPU bound, but deals essentially with modeling a large 
> number of independent cells (a sort of massively parallel « Game of life »), 
> where each cells lives in its own process, it makes more sense to model it in 
> Golang rather than rust?
> 
> -- 
> 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/87f2cdd8-1968-445d-b2bc-eae349ae5687%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/AC558F7E-712B-4F26-B402-00F98514511A%40ix.netcom.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Serge Hulne]

Am I therefore correct in assuming that, if the problem I am trying to model is 
not IO bound or CPU bound, but deals essentially with modeling a large number 
of independent cells (a sort of massively parallel « Game of life »), where 
each cells lives in its own process, it makes more sense to model it in Golang 
rather than rust?

-- 
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/87f2cdd8-1968-445d-b2bc-eae349ae5687%40googlegroups.com.

Re: [go-nuts] Go gouroutines vs Rust threads

[Russel Winder]

On Wed, 2019-11-13 at 05:14 -0800, Serge Hulne wrote:
> Does anybody know if Rust threads are lightweight processes like Go
> goroutines or if they rely on system threads (i.e. more like the Python
> approach) ?

Rust std::thread is all about OS threads. There are many crates dealing with
threadpools, work-stealing, etc. e.g Rayon.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

-- 
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/75c2d782386201aed8ba72c89daf88f23f8c8a59.camel%40winder.org.uk.


signature.asc
Description: This is a digitally signed message part

[go-nuts] Go gouroutines vs Rust threads

[Serge Hulne]

Does anybody know if Rust threads are lightweight processes like Go goroutines 
or if they rely on system threads (i.e. more like the Python approach) ?

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/4bf0722d-a444-4127-9aa2-76b038a2ac7d%40googlegroups.com.

[go-nuts] using or extending or forking+renaming github.com/google/licensecheck to provide similar functionality

[fgergo]

Hi,

 "licensecheck classifies license files and heuristically determines
how well they correspond to known open source licenses."

I'd like to identify license references in the file system. If I
understand correctly package licensecheck in it's current form is not
useful to help with this.
If it's still possible, could you please share a hint how to do that?
(input: byte array, output: license references in the byte array)
If I understand correctly and I can't use licensecheck in it's current
form, which one is preferred:
extend current api, (maybe: func Refers(input []byte) (References,
bool) or fork+rename the package? (References{...} being similar to
Coverage{...})

thanks,
Gergely Födémesi

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