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

[robert engels]

I think an easier way is to enable the http based profiling, then just request 
the profile using the web interface using N seconds - much easier. You can make 
enabling the http profiling a compile time option.

> On Nov 14, 2019, at 10:41 PM, Michael Jones  wrote:
> 
> If your program is endless, then you'll need to have a timer that says "it's 
> been long enough, write the profile now"
> 
> On Thu, Nov 14, 2019 at 9:35 AM bln prasad  > wrote:
> My applications main starts few go routines and runs indefinitely. its like 
> pprof.StopCPUProfile() may never get called. 
> 
> Thanks,
> BLN
> 
> On Wednesday, 13 November 2019 23:30:47 UTC+5:30, Ian Lance Taylor wrote:
> 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/44a1f5ef-f289-499c-b35c-c56c5f1bf936%40googlegroups.com
>  
> .
> 
> 
> -- 
> Michael T. Jones
> michael.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/CALoEmQyz%3Dcc-EejPyx-ZCWfKN_hFD%2BGZiKwZkRjFEjr-WPZCeA%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/6F26DD8F-DE79-4EB5-8444-22A66D6FBED4%40ix.netcom.com.

[go-nuts] golang tool for splitting long lines

[Sankar]

Hi

In Javascript world I have this handy tool Prettier which will 
automatically, reproducibly break long lines of code into multiple lines 
(and also merge parameters into a single line if some elements are 
removed). 

Are there similar tools available for Golang ? Either as a standalone 
program or as VSCode/Goland plugins.

>From https://github.com/golang/go/issues/11915 I believe that go team may 
not address it as natively as gofmt/goimports. But are there any other 
hacks/tools that people already use to break long lines ? 

Thanks.

Sankar

-- 
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/063ade8f-ffd2-4481-891a-c8fe7cb480ef%40googlegroups.com.

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

[Michael Jones]

If your program is endless, then you'll need to have a timer that says
"it's been long enough, write the profile now"

On Thu, Nov 14, 2019 at 9:35 AM bln prasad  wrote:

> My applications main starts few go routines and runs indefinitely. its
> like pprof.StopCPUProfile() may never get called.
>
> Thanks,
> BLN
>
> On Wednesday, 13 November 2019 23:30:47 UTC+5:30, Ian Lance Taylor wrote:
>>
>> 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/44a1f5ef-f289-499c-b35c-c56c5f1bf936%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/CALoEmQyz%3Dcc-EejPyx-ZCWfKN_hFD%2BGZiKwZkRjFEjr-WPZCeA%40mail.gmail.com.

[go-nuts] ANN: goht v1.0, a minimalist package for creating web content in Go

[Michael Ellis]

https://github.com/Michael-F-Ellis/goht

Easy to learn and practical for simple web development. I developed it for 
use in my own work and it seems worth sharing.

Cheers,
Mike

-- 
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/769e2aa9-ee80-4d1d-b540-bae2b20da7ae%40googlegroups.com.

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

[bln prasad]

My applications main starts few go routines and runs indefinitely. its like 
pprof.StopCPUProfile() may never get called. 

Thanks,
BLN

On Wednesday, 13 November 2019 23:30:47 UTC+5:30, Ian Lance Taylor wrote:
>
> 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/44a1f5ef-f289-499c-b35c-c56c5f1bf936%40googlegroups.com.

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

[Jake Montgomery]

On Wednesday, November 13, 2019 at 3:22:56 PM UTC-5, 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?
>
 
I don't think it does, and that would not even be possible. If it did just 
use a pointer to the original value then modifications to the original 
would be reflected in the interface. If the interface holds a value, not a 
pointer, then that would be very unexpected. I think this code 
https://play.golang.org/p/9H4AFIGy-1I illustrates that a copy is indeed 
made when a interface holds a value. 

-- 
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/219fabe2-b555-48b5-b022-926ba131b91c%40googlegroups.com.

Re: [go-nuts] Re: Go WebAssembly(wasm) testing fails - fatal error: unexpected signal during runtime execution

[Agniva De Sarker]

Please also try with 1.13.x and see if you see the issue there too. Also
please try running manually in FF too.

On Thu, Nov 14, 2019 at 10:08 PM mihai barbulescu  wrote:

> - Are you able to provide the code which causes this crash ?
>  Not really...it's a big code-base... I will try to reproduce a smaller
> testcase and update the post.
> - Which Go version are you using ?
> go tip
> - Are you testing this in the browser or in Node ? Please give details of
> either.
> In the browser (sort of )
>
> https://github.com/golang/go/wiki/WebAssembly#running-tests-in-the-browser
>
> joi, 14 noiembrie 2019, 18:33:48 UTC+2, Agniva De Sarker a scris:
>>
>> Please provide more information so that it helps people to debug the
>> issue. Such as:
>>
>> - Are you able to provide the code which causes this crash ?
>> - Which Go version are you using ?
>> - Are you testing this in the browser or in Node ? Please give details of
>> either.
>>
>>
>>
>> On Thursday, 14 November 2019 18:52:49 UTC+5:30, mihai barbulescu wrote:
>>>
>>> I'm building a client-side webapp and part of this I would like to run
>>> tests. It seems testing fails . Is it a known issue ?
>>>
>>>
>>> Mihai
>>>
>>> server thetv$ GOOS=js GOARCH=wasm go test
>>> --- FAIL: TestServer (3.00s)
>>> fatal error: unexpected signal during runtime execution
>>>
>>> runtime stack:
>>> runtime: unexpected return pc for syscall.fsCall called from
>>> 0x15d70a5c1ade6900
>>> stack: frame={sp:0xb23170, fp:0xb23208} stack=[0xb21698,0xb23298)
>>> 00b23070:  00143b44  002a
>>> 00b23080:  00b00de0  10e20003
>>> 
>>> 00b23090:  0001  000b52bf
>>> 00b230a0:  5bab0011 
>>> 00c3e368
>>> 00b230b0:  00c3e3b8  105e001a
>>> 
>>> 00b230c0:    00b231e8
>>> 00b230d0:  0005  
>>> 00b230e0:  109e0010 
>>> 
>>> 00b230f0:  0003  0005
>>> 00b23100:  008affbb0c00  0001
>>> 00b23110:  15d709d10001  15d70a5c1ade6900
>>> 00b23120:  00c32300  00c30058
>>> 00b23130:    008e6901
>>> 00b23140:  105d0002 
>>> 00c3
>>> 00b23150:  00b231e8  0001
>>> 00b23160:  00b06600  1512000d
>>> 
>>> 00b23170: <00c3  00b231e8
>>> 00b23180:  12250010 
>>> 00010001
>>> 00b23190:  0001  00c3e3b8
>>> 00b231a0:    00c305d8
>>> 00b231b0:  15d709d10005  00c3
>>> 00b231c0:  00050004  00b00de0
>>> 00b231d0:  15d709d11b235d00  00c3
>>> 00b231e0:  1248005e 
>>> 
>>> 00b231f0:    
>>> 00b23200: !15d70a5c1ade6900 >10a0
>>> 
>>> 00b23210:  00ac0820  1354
>>> 
>>> 00b23220:  10a0 
>>> 00b00de0
>>> 00b23230:  00c00c90  0006
>>> 00b23240:  1251002b 
>>> 00c3
>>> 00b23250:  00c00c00  00c00900
>>> 00b23260:  00040002  
>>> 00b23270:  00b00de0  13b40001 
>>> 00b23280:  00c00c00  00b232c0
>>> 00b23290:  0100
>>> syscall.fsCall(0x10a0, 0xac0820, 0x1354, 0x10a0, 0xb00de0,
>>> 0xc00c90, 0x6, 0x1251002b)
>>> /Users/thetv/goroot/src/syscall/fs_js.go:513 +0xd
>>>
>>> goroutine 1 [chan receive]:
>>> testing.(*T).Run(0xca4100, 0x137b68, 0xa, 0x14f008, 0x155b0002)
>>> /Users/thetv/goroot/src/testing/testing.go:977 +0x31
>>> testing.runTests.func1(0xca4000)
>>> /Users/thetv/goroot/src/testing/testing.go:1218 +0x5
>>> testing.tRunner(0xca4000, 0xc56e28)
>>> /Users/thetv/goroot/src/testing/testing.go:925 +0xc
>>> testing.runTests(0xc0a240, 0xaee440, 0x1, 0x1, 0x0)
>>> /Users/thetv/goroot/src/testing/testing.go:1216 +0x28
>>> testing.(*M).Run(0xca2000, 0x0)
>>> /Users/thetv/goroot/src/testing/testing.go:1133 +0x1b
>>> main.main()
>>> _testmain.go:44 +0xd
>>>
>>> goroutine 6 [waiting]:
>>> syscall/js.Value.Call(0x7ff8000a, 0x13655c, 0x5, 0xc76aa0, 0x6,
>>> 0xa, 0x5)
>>> /Users/thetv/goroot/src/syscall/js/js.go:326 +0x3
>>> syscall.fsCall(0x13655c, 0x5, 0xc58bf8, 0x5, 0x5, 0x401, 0x1378ac0,
>>> 0x3)
>>> /Users/thetv/goroot/src/syscall/fs_js.go:496 +0xc
>>> syscall.Write(0x1, 0xc74400, 0x1d, 0x400, 0x1d, 0xb2ee68, 0xcac500)
>>> /Users/thetv/goroot/src/syscall/fs_js.go:417 +0x11
>>> internal/poll.(*FD).Write(0xc3e120, 0xc74400, 0x1d, 0x400, 0x0, 0x0, 0x0)
>>> /Users/thetv/goroot/src/internal/poll/fd_unix.go:268 +0x2

[go-nuts] Re: Go WebAssembly(wasm) testing fails - fatal error: unexpected signal during runtime execution

[mihai barbulescu]

- Are you able to provide the code which causes this crash ?
 Not really...it's a big code-base... I will try to reproduce a smaller 
testcase and update the post.
- Which Go version are you using ?
go tip
- Are you testing this in the browser or in Node ? Please give details of 
either.
In the browser (sort of ) 

https://github.com/golang/go/wiki/WebAssembly#running-tests-in-the-browser

joi, 14 noiembrie 2019, 18:33:48 UTC+2, Agniva De Sarker a scris:
>
> Please provide more information so that it helps people to debug the 
> issue. Such as:
>
> - Are you able to provide the code which causes this crash ?
> - Which Go version are you using ?
> - Are you testing this in the browser or in Node ? Please give details of 
> either.
>
>
>
> On Thursday, 14 November 2019 18:52:49 UTC+5:30, mihai barbulescu wrote:
>>
>> I'm building a client-side webapp and part of this I would like to run 
>> tests. It seems testing fails . Is it a known issue ?
>>
>>
>> Mihai
>>
>> server thetv$ GOOS=js GOARCH=wasm go test 
>> --- FAIL: TestServer (3.00s)
>> fatal error: unexpected signal during runtime execution
>>
>> runtime stack:
>> runtime: unexpected return pc for syscall.fsCall called from 
>> 0x15d70a5c1ade6900
>> stack: frame={sp:0xb23170, fp:0xb23208} stack=[0xb21698,0xb23298)
>> 00b23070:  00143b44  002a 
>> 00b23080:  00b00de0  10e20003 
>>  
>> 00b23090:  0001  000b52bf 
>> 00b230a0:  5bab0011   
>> 00c3e368 
>> 00b230b0:  00c3e3b8  105e001a 
>>  
>> 00b230c0:    00b231e8 
>> 00b230d0:  0005   
>> 00b230e0:  109e0010   
>>  
>> 00b230f0:  0003  0005 
>> 00b23100:  008affbb0c00  0001 
>> 00b23110:  15d709d10001  15d70a5c1ade6900 
>> 00b23120:  00c32300  00c30058 
>> 00b23130:    008e6901 
>> 00b23140:  105d0002   
>> 00c3 
>> 00b23150:  00b231e8  0001 
>> 00b23160:  00b06600  1512000d  
>> 00b23170: <00c3  00b231e8 
>> 00b23180:  12250010   
>> 00010001 
>> 00b23190:  0001  00c3e3b8 
>> 00b231a0:    00c305d8 
>> 00b231b0:  15d709d10005  00c3 
>> 00b231c0:  00050004  00b00de0 
>> 00b231d0:  15d709d11b235d00  00c3 
>> 00b231e0:  1248005e   
>>  
>> 00b231f0:     
>> 00b23200: !15d70a5c1ade6900 >10a0 
>>  
>> 00b23210:  00ac0820  1354 
>>  
>> 00b23220:  10a0   
>> 00b00de0 
>> 00b23230:  00c00c90  0006 
>> 00b23240:  1251002b   
>> 00c3 
>> 00b23250:  00c00c00  00c00900 
>> 00b23260:  00040002   
>> 00b23270:  00b00de0  13b40001  
>> 00b23280:  00c00c00  00b232c0 
>> 00b23290:  0100 
>> syscall.fsCall(0x10a0, 0xac0820, 0x1354, 0x10a0, 0xb00de0, 
>> 0xc00c90, 0x6, 0x1251002b)
>> /Users/thetv/goroot/src/syscall/fs_js.go:513 +0xd
>>
>> goroutine 1 [chan receive]:
>> testing.(*T).Run(0xca4100, 0x137b68, 0xa, 0x14f008, 0x155b0002)
>> /Users/thetv/goroot/src/testing/testing.go:977 +0x31
>> testing.runTests.func1(0xca4000)
>> /Users/thetv/goroot/src/testing/testing.go:1218 +0x5
>> testing.tRunner(0xca4000, 0xc56e28)
>> /Users/thetv/goroot/src/testing/testing.go:925 +0xc
>> testing.runTests(0xc0a240, 0xaee440, 0x1, 0x1, 0x0)
>> /Users/thetv/goroot/src/testing/testing.go:1216 +0x28
>> testing.(*M).Run(0xca2000, 0x0)
>> /Users/thetv/goroot/src/testing/testing.go:1133 +0x1b
>> main.main()
>> _testmain.go:44 +0xd
>>
>> goroutine 6 [waiting]:
>> syscall/js.Value.Call(0x7ff8000a, 0x13655c, 0x5, 0xc76aa0, 0x6, 
>> 0xa, 0x5)
>> /Users/thetv/goroot/src/syscall/js/js.go:326 +0x3
>> syscall.fsCall(0x13655c, 0x5, 0xc58bf8, 0x5, 0x5, 0x401, 0x1378ac0, 
>> 0x3)
>> /Users/thetv/goroot/src/syscall/fs_js.go:496 +0xc
>> syscall.Write(0x1, 0xc74400, 0x1d, 0x400, 0x1d, 0xb2ee68, 0xcac500)
>> /Users/thetv/goroot/src/syscall/fs_js.go:417 +0x11
>> internal/poll.(*FD).Write(0xc3e120, 0xc74400, 0x1d, 0x400, 0x0, 0x0, 0x0)
>> /Users/thetv/goroot/src/internal/poll/fd_unix.go:268 +0x22
>> os.(*File).write(...)
>> /Users/thetv/goroot/src/os/file_unix.go:280
>> os.(*File).Write(0xc0c020, 0xc74400, 0x1d, 0x400, 0x3, 0x3, 0xc2ce01)
>> /Users/thetv/goroot/src/os/file.go:153 +0xf
>> fmt.Fprintf(0x1949c0, 0

[go-nuts] Re: Go WebAssembly(wasm) testing fails - fatal error: unexpected signal during runtime execution

[Agniva De Sarker]

Please provide more information so that it helps people to debug the issue. 
Such as:

- Are you able to provide the code which causes this crash ?
- Which Go version are you using ?
- Are you testing this in the browser or in Node ? Please give details of 
either.



On Thursday, 14 November 2019 18:52:49 UTC+5:30, mihai barbulescu wrote:
>
> I'm building a client-side webapp and part of this I would like to run 
> tests. It seems testing fails . Is it a known issue ?
>
>
> Mihai
>
> server thetv$ GOOS=js GOARCH=wasm go test 
> --- FAIL: TestServer (3.00s)
> fatal error: unexpected signal during runtime execution
>
> runtime stack:
> runtime: unexpected return pc for syscall.fsCall called from 
> 0x15d70a5c1ade6900
> stack: frame={sp:0xb23170, fp:0xb23208} stack=[0xb21698,0xb23298)
> 00b23070:  00143b44  002a 
> 00b23080:  00b00de0  10e20003 
>  
> 00b23090:  0001  000b52bf 
> 00b230a0:  5bab0011   
> 00c3e368 
> 00b230b0:  00c3e3b8  105e001a 
>  
> 00b230c0:    00b231e8 
> 00b230d0:  0005   
> 00b230e0:  109e0010   
>  
> 00b230f0:  0003  0005 
> 00b23100:  008affbb0c00  0001 
> 00b23110:  15d709d10001  15d70a5c1ade6900 
> 00b23120:  00c32300  00c30058 
> 00b23130:    008e6901 
> 00b23140:  105d0002   
> 00c3 
> 00b23150:  00b231e8  0001 
> 00b23160:  00b06600  1512000d  
> 00b23170: <00c3  00b231e8 
> 00b23180:  12250010   
> 00010001 
> 00b23190:  0001  00c3e3b8 
> 00b231a0:    00c305d8 
> 00b231b0:  15d709d10005  00c3 
> 00b231c0:  00050004  00b00de0 
> 00b231d0:  15d709d11b235d00  00c3 
> 00b231e0:  1248005e   
>  
> 00b231f0:     
> 00b23200: !15d70a5c1ade6900 >10a0 
>  
> 00b23210:  00ac0820  1354 
>  
> 00b23220:  10a0   
> 00b00de0 
> 00b23230:  00c00c90  0006 
> 00b23240:  1251002b   00c3 
> 00b23250:  00c00c00  00c00900 
> 00b23260:  00040002   
> 00b23270:  00b00de0  13b40001  
> 00b23280:  00c00c00  00b232c0 
> 00b23290:  0100 
> syscall.fsCall(0x10a0, 0xac0820, 0x1354, 0x10a0, 0xb00de0, 
> 0xc00c90, 0x6, 0x1251002b)
> /Users/thetv/goroot/src/syscall/fs_js.go:513 +0xd
>
> goroutine 1 [chan receive]:
> testing.(*T).Run(0xca4100, 0x137b68, 0xa, 0x14f008, 0x155b0002)
> /Users/thetv/goroot/src/testing/testing.go:977 +0x31
> testing.runTests.func1(0xca4000)
> /Users/thetv/goroot/src/testing/testing.go:1218 +0x5
> testing.tRunner(0xca4000, 0xc56e28)
> /Users/thetv/goroot/src/testing/testing.go:925 +0xc
> testing.runTests(0xc0a240, 0xaee440, 0x1, 0x1, 0x0)
> /Users/thetv/goroot/src/testing/testing.go:1216 +0x28
> testing.(*M).Run(0xca2000, 0x0)
> /Users/thetv/goroot/src/testing/testing.go:1133 +0x1b
> main.main()
> _testmain.go:44 +0xd
>
> goroutine 6 [waiting]:
> syscall/js.Value.Call(0x7ff8000a, 0x13655c, 0x5, 0xc76aa0, 0x6, 
> 0xa, 0x5)
> /Users/thetv/goroot/src/syscall/js/js.go:326 +0x3
> syscall.fsCall(0x13655c, 0x5, 0xc58bf8, 0x5, 0x5, 0x401, 0x1378ac0, 
> 0x3)
> /Users/thetv/goroot/src/syscall/fs_js.go:496 +0xc
> syscall.Write(0x1, 0xc74400, 0x1d, 0x400, 0x1d, 0xb2ee68, 0xcac500)
> /Users/thetv/goroot/src/syscall/fs_js.go:417 +0x11
> internal/poll.(*FD).Write(0xc3e120, 0xc74400, 0x1d, 0x400, 0x0, 0x0, 0x0)
> /Users/thetv/goroot/src/internal/poll/fd_unix.go:268 +0x22
> os.(*File).write(...)
> /Users/thetv/goroot/src/os/file_unix.go:280
> os.(*File).Write(0xc0c020, 0xc74400, 0x1d, 0x400, 0x3, 0x3, 0xc2ce01)
> /Users/thetv/goroot/src/os/file.go:153 +0xf
> fmt.Fprintf(0x1949c0, 0xc0c020, 0x139be8, 0x10, 0xc58e78, 0x3, 0x3, 
> 0xb232c8, 0x0, 0x19340006)
> /Users/thetv/goroot/src/fmt/print.go:205 +0x8
> testing.(*common).flushToParent(0xca4100, 0x139be8, 0x10, 0xc58e78, 0x3, 
> 0x3)
> /Users/thetv/goroot/src/testing/testing.go:508 +0x7
> testing.(*T).report(0xca4100)
> /Users/thetv/goroot/src/testing/testing.go:1155 +0x18
> testing.tRunner.func1(0xca4100)
> /Users/thetv/goroot/src/testing/testing.go:912 +0x41
> testing.tRunner(0xca4100, 0x14f008)
> /Users/thetv/goroot/src/testing/testing.go:929 +0xd
> create

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

[sbs . 191197]

Hi, 

I am a Software Engineer working at a Fashion E-Commerce company in India. 
Golang has been a part of our journey for the last 2-3 years and has 
allowed us to scale massively in the past 2-3 years. Would it be okay if we 
send out an article regarding our journey with Golang over the past 2-3 
years. 

Best regards,
Salman Shah. 

On Wednesday, November 13, 2019 at 10:46:46 PM UTC+5:30, Julie Qiu 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/923dea98-548f-4156-9632-72569dbd83bd%40googlegroups.com.

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

[Mohamed Yousif]

Is there any plans on open sourcing go.dev (the webservices behind it). It
is a little bit odd, but I'll personally learn a lot from it.

Oh, and congrats on the great work. I really liked it so much and would
definitely use it a lot over godoc.

Regards,
M

On Thu, Nov 14, 2019 at 12:00 PM Dan Kortschak  wrote:

> Yes. This is my exact concern.
>
> This has two impacts, one is the non-discoverability and the other is a
> possibility of misapprehension that the packages are in fact non-
> licensed which is an actual harm to the packages. The irony is that we
> have gone to excessive lengths to ensure that all our original sources
> have their licenses represented as well.
>
> On Thu, 2019-11-14 at 10:56 +0100, Jan Mercl wrote:
> > On Thu, Nov 14, 2019 at 5:55 AM Dan Kortschak 
> > wrote:
> >
> > > 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.
> >
> > Moreover, such packages seem to be, as a side effect, non-
> > discoverable
> > because their README and documentation are not indexed (nor
> > displayed). For example, searching for `pure go SQL database' has
> > zero
> > results.
> >
> > I don't care about automatic license recognizing, even though it's
> > admittedly a useful information for the site user. But I don't
> > understand why projects with unrecognized LICENSE file contents don't
> > show the README and the documentation.
> >
> > I'll better leave the fact of hiding even the LICENSE file per se
> > from
> > the user with the message `“Licenses” hidden due to license
> > restrictions.` without comment because I guess it's just a legal
> > issue
> > I don't understand.
> >
> > Any yes, all my packages that I tried are victims to the above
> > issues.
> > Here's an example of a recognized LICENSE vs an  unrecognized one:
> >
> > jnml@e5-1650:~/src/modernc.org/mathutil> diff -u ~/goroot/LICENSE
> > LICENSE
> > --- /home/jnml/goroot/LICENSE 2019-09-10 14:24:54.469859557 +0200
> > +++ LICENSE 2019-09-10 14:36:43.347068286 +0200
> > @@ -1,4 +1,4 @@
> > -Copyright (c) 2009 The Go Authors. All rights reserved.
> > +Copyright (c) 2014 The mathutil Authors. All rights reserved.
> >
> >  Redistribution and use in source and binary forms, with or without
> >  modification, are permitted provided that the following conditions
> > are
> > @@ -10,7 +10,7 @@
> >  copyright notice, this list of conditions and the following
> > disclaimer
> >  in the documentation and/or other materials provided with the
> >  distribution.
> > -   * Neither the name of Google Inc. nor the names of its
> > +   * Neither the names of the authors nor the names of the
> >  contributors may be used to endorse or promote products derived from
> >  this software without specific prior written permission.
> >
> > jnml@e5-1650:~/src/modernc.org/mathutil>
> >
>
> --
> 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/7b8e08bb8429ac6b245458b33df597b783e0180b.camel%40kortschak.io
> .
>

-- 
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/CAHrL7wENOSm0kWkQojDnbdM%2B27o1a0B%2Bw4rthMUoamsPrEvFdw%40mail.gmail.com.

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

[Dan Kortschak]

Yes. This is my exact concern.

This has two impacts, one is the non-discoverability and the other is a
possibility of misapprehension that the packages are in fact non-
licensed which is an actual harm to the packages. The irony is that we
have gone to excessive lengths to ensure that all our original sources
have their licenses represented as well.

On Thu, 2019-11-14 at 10:56 +0100, Jan Mercl wrote:
> On Thu, Nov 14, 2019 at 5:55 AM Dan Kortschak 
> wrote:
> 
> > 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.
> 
> Moreover, such packages seem to be, as a side effect, non-
> discoverable
> because their README and documentation are not indexed (nor
> displayed). For example, searching for `pure go SQL database' has
> zero
> results.
> 
> I don't care about automatic license recognizing, even though it's
> admittedly a useful information for the site user. But I don't
> understand why projects with unrecognized LICENSE file contents don't
> show the README and the documentation.
> 
> I'll better leave the fact of hiding even the LICENSE file per se
> from
> the user with the message `“Licenses” hidden due to license
> restrictions.` without comment because I guess it's just a legal
> issue
> I don't understand.
> 
> Any yes, all my packages that I tried are victims to the above
> issues.
> Here's an example of a recognized LICENSE vs an  unrecognized one:
> 
> jnml@e5-1650:~/src/modernc.org/mathutil> diff -u ~/goroot/LICENSE
> LICENSE
> --- /home/jnml/goroot/LICENSE 2019-09-10 14:24:54.469859557 +0200
> +++ LICENSE 2019-09-10 14:36:43.347068286 +0200
> @@ -1,4 +1,4 @@
> -Copyright (c) 2009 The Go Authors. All rights reserved.
> +Copyright (c) 2014 The mathutil Authors. All rights reserved.
> 
>  Redistribution and use in source and binary forms, with or without
>  modification, are permitted provided that the following conditions
> are
> @@ -10,7 +10,7 @@
>  copyright notice, this list of conditions and the following
> disclaimer
>  in the documentation and/or other materials provided with the
>  distribution.
> -   * Neither the name of Google Inc. nor the names of its
> +   * Neither the names of the authors nor the names of the
>  contributors may be used to endorse or promote products derived from
>  this software without specific prior written permission.
> 
> jnml@e5-1650:~/src/modernc.org/mathutil>
> 

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

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

[fgergo]

Sorry I did not read your response fully. Repeating the matching is just fine.
Thanks again!

On Thu, Nov 14, 2019 at 10:56 AM  wrote:
>
> Thanks, I did not realize that Coverage -> Match[n] could be that useful!
> Though the field Match.Name is not a file name I can os.Open().
> How can I directly access the known license texts?
>
>
> On Thu, Nov 14, 2019 at 10:42 AM Dan Kortschak  wrote:
> >
> > The licensecheck.Match type holds the start and end offsets in the
> > file. Can't you use that to extract the license portion and either
> > check it's length against the length of the license or repeat the Check
> > with only that portion of the file?
> >
> > On Thu, 2019-11-14 at 10:24 +0100, fge...@gmail.com wrote:
> > > Sorry if I was not clear: on walking the file system, that's clear, I
> > > did not intend to talk about that, only about matching and reporting
> > > on matching. The example I gave was just to put in context why I
> > > believe I'd need a different api.
> > >
> > > Using the Options field is good enough in the first example. (That's
> > > how I used licensecheck first.)
> > > Although for the second example Cover() does not report what I'd
> > > need.
> > >
> > > As far as I've seen currently using func Cover(INPUT []byte, opts
> > > Options) (Coverage, bool) reports 100% MIT if INPUT matches byte for
> > > byte 100% MIT. If INPUT has more text than the complete 100% matching
> > > text of  MIT license, for example the MIT license is only in the
> > > beginning of INPUT and the rest of INPUT is for example Go code, than
> > > Coverage will report len(INPUT)/len(MIT license) which is less than
> > > 100%.
> > >
> > > In this case, the new api would report 100%, since input contains
> > > 100%
> > > MIT license text (and some programming code, which is not relevant
> > > here).
> > >
> > > If I understand correctly the current api is for checking _already_
> > > identified license files, which contain _only_ the license text.
> > > I believe to look for files containing - complete or possibly broken
> > > -
> > > license references a different matching is needed.
> > >
> > >
> > > On 11/14/19, Rob Pike  wrote:
> > > > As I understand what you're trying to do, you just need to write a
> > > > tree
> > > > walker, perhaps using filepath.Walk, that opens each file and calls
> > > > Cover
> > > > on it. You can set the Options field to control the threshold for
> > > > reporting, and use the result of that to choose which licenses to
> > > > report.
> > > >
> > > > I don't believe an API change is called for.
> > > >
> > > > -rob
> > > >
> > > >
> > > > On Thu, Nov 14, 2019 at 6:14 PM  wrote:
> > > >
> > > > > 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 fi

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

[fgergo]

Thanks, I did not realize that Coverage -> Match[n] could be that useful!
Though the field Match.Name is not a file name I can os.Open().
How can I directly access the known license texts?


On Thu, Nov 14, 2019 at 10:42 AM Dan Kortschak  wrote:
>
> The licensecheck.Match type holds the start and end offsets in the
> file. Can't you use that to extract the license portion and either
> check it's length against the length of the license or repeat the Check
> with only that portion of the file?
>
> On Thu, 2019-11-14 at 10:24 +0100, fge...@gmail.com wrote:
> > Sorry if I was not clear: on walking the file system, that's clear, I
> > did not intend to talk about that, only about matching and reporting
> > on matching. The example I gave was just to put in context why I
> > believe I'd need a different api.
> >
> > Using the Options field is good enough in the first example. (That's
> > how I used licensecheck first.)
> > Although for the second example Cover() does not report what I'd
> > need.
> >
> > As far as I've seen currently using func Cover(INPUT []byte, opts
> > Options) (Coverage, bool) reports 100% MIT if INPUT matches byte for
> > byte 100% MIT. If INPUT has more text than the complete 100% matching
> > text of  MIT license, for example the MIT license is only in the
> > beginning of INPUT and the rest of INPUT is for example Go code, than
> > Coverage will report len(INPUT)/len(MIT license) which is less than
> > 100%.
> >
> > In this case, the new api would report 100%, since input contains
> > 100%
> > MIT license text (and some programming code, which is not relevant
> > here).
> >
> > If I understand correctly the current api is for checking _already_
> > identified license files, which contain _only_ the license text.
> > I believe to look for files containing - complete or possibly broken
> > -
> > license references a different matching is needed.
> >
> >
> > On 11/14/19, Rob Pike  wrote:
> > > As I understand what you're trying to do, you just need to write a
> > > tree
> > > walker, perhaps using filepath.Walk, that opens each file and calls
> > > Cover
> > > on it. You can set the Options field to control the threshold for
> > > reporting, and use the result of that to choose which licenses to
> > > report.
> > >
> > > I don't believe an API change is called for.
> > >
> > > -rob
> > >
> > >
> > > On Thu, Nov 14, 2019 at 6:14 PM  wrote:
> > >
> > > > 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 W

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

[Jan Mercl]

On Thu, Nov 14, 2019 at 5:55 AM Dan Kortschak  wrote:

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

Moreover, such packages seem to be, as a side effect, non-discoverable
because their README and documentation are not indexed (nor
displayed). For example, searching for `pure go SQL database' has zero
results.

I don't care about automatic license recognizing, even though it's
admittedly a useful information for the site user. But I don't
understand why projects with unrecognized LICENSE file contents don't
show the README and the documentation.

I'll better leave the fact of hiding even the LICENSE file per se from
the user with the message `“Licenses” hidden due to license
restrictions.` without comment because I guess it's just a legal issue
I don't understand.

Any yes, all my packages that I tried are victims to the above issues.
Here's an example of a recognized LICENSE vs an  unrecognized one:

jnml@e5-1650:~/src/modernc.org/mathutil> diff -u ~/goroot/LICENSE LICENSE
--- /home/jnml/goroot/LICENSE 2019-09-10 14:24:54.469859557 +0200
+++ LICENSE 2019-09-10 14:36:43.347068286 +0200
@@ -1,4 +1,4 @@
-Copyright (c) 2009 The Go Authors. All rights reserved.
+Copyright (c) 2014 The mathutil Authors. All rights reserved.

 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are
@@ -10,7 +10,7 @@
 copyright notice, this list of conditions and the following disclaimer
 in the documentation and/or other materials provided with the
 distribution.
-   * Neither the name of Google Inc. nor the names of its
+   * Neither the names of the authors nor the names of the
 contributors may be used to endorse or promote products derived from
 this software without specific prior written permission.

jnml@e5-1650:~/src/modernc.org/mathutil>

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

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

[Dan Kortschak]

The licensecheck.Match type holds the start and end offsets in the
file. Can't you use that to extract the license portion and either
check it's length against the length of the license or repeat the Check
with only that portion of the file?

On Thu, 2019-11-14 at 10:24 +0100, fge...@gmail.com wrote:
> Sorry if I was not clear: on walking the file system, that's clear, I
> did not intend to talk about that, only about matching and reporting
> on matching. The example I gave was just to put in context why I
> believe I'd need a different api.
> 
> Using the Options field is good enough in the first example. (That's
> how I used licensecheck first.)
> Although for the second example Cover() does not report what I'd
> need.
> 
> As far as I've seen currently using func Cover(INPUT []byte, opts
> Options) (Coverage, bool) reports 100% MIT if INPUT matches byte for
> byte 100% MIT. If INPUT has more text than the complete 100% matching
> text of  MIT license, for example the MIT license is only in the
> beginning of INPUT and the rest of INPUT is for example Go code, than
> Coverage will report len(INPUT)/len(MIT license) which is less than
> 100%.
> 
> In this case, the new api would report 100%, since input contains
> 100%
> MIT license text (and some programming code, which is not relevant
> here).
> 
> If I understand correctly the current api is for checking _already_
> identified license files, which contain _only_ the license text.
> I believe to look for files containing - complete or possibly broken
> -
> license references a different matching is needed.
> 
> 
> On 11/14/19, Rob Pike  wrote:
> > As I understand what you're trying to do, you just need to write a
> > tree
> > walker, perhaps using filepath.Walk, that opens each file and calls
> > Cover
> > on it. You can set the Options field to control the threshold for
> > reporting, and use the result of that to choose which licenses to
> > report.
> > 
> > I don't believe an API change is called for.
> > 
> > -rob
> > 
> > 
> > On Thu, Nov 14, 2019 at 6:14 PM  wrote:
> > 
> > > 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 po

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

[fgergo]

Sorry if I was not clear: on walking the file system, that's clear, I
did not intend to talk about that, only about matching and reporting
on matching. The example I gave was just to put in context why I
believe I'd need a different api.

Using the Options field is good enough in the first example. (That's
how I used licensecheck first.)
Although for the second example Cover() does not report what I'd need.

As far as I've seen currently using func Cover(INPUT []byte, opts
Options) (Coverage, bool) reports 100% MIT if INPUT matches byte for
byte 100% MIT. If INPUT has more text than the complete 100% matching
text of  MIT license, for example the MIT license is only in the
beginning of INPUT and the rest of INPUT is for example Go code, than
Coverage will report len(INPUT)/len(MIT license) which is less than
100%.

In this case, the new api would report 100%, since input contains 100%
MIT license text (and some programming code, which is not relevant
here).

If I understand correctly the current api is for checking _already_
identified license files, which contain _only_ the license text.
I believe to look for files containing - complete or possibly broken -
license references a different matching is needed.


On 11/14/19, Rob Pike  wrote:
> As I understand what you're trying to do, you just need to write a tree
> walker, perhaps using filepath.Walk, that opens each file and calls Cover
> on it. You can set the Options field to control the threshold for
> reporting, and use the result of that to choose which licenses to report.
>
> I don't believe an API change is called for.
>
> -rob
>
>
> On Thu, Nov 14, 2019 at 6:14 PM  wrote:
>
>> 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

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

[Ian Davis]

On Thu, 14 Nov 2019, at 4:54 AM, 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.
> 

It does seem that something is amiss with license detection. For example Github 
detects the use of the UNLICENSE just fine for https://github.com/iand/salience 
but go.dev misses it completely and refuses to display the readme. 

-- 
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/625cb68d-116d-4b17-a251-94d6ae9b208a%40www.fastmail.com.

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

[Rob Pike]

As I understand what you're trying to do, you just need to write a tree
walker, perhaps using filepath.Walk, that opens each file and calls Cover
on it. You can set the Options field to control the threshold for
reporting, and use the result of that to choose which licenses to report.

I don't believe an API change is called for.

-rob


On Thu, Nov 14, 2019 at 6:14 PM  wrote:

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