Re: [go-nuts] Re: How to manage multiple versions of Go?

[fgergo]

You can also 'go get' most go versions and it's quite robust.
https://twitter.com/golang/status/875117556595515392


On Mon, Jun 26, 2017 at 5:17 PM, Igor Maznitsa  wrote:
> mvn-golang plugin also allows to automate work with multiple versions of Go
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: How to manage multiple versions of Go?

[fgergo]

Sorry, I'll correct myself:
godoc.org/golang.org/x/build/version
only handles the listed directories.
Though if for example you copy an existing directory to go1.8.3 and
trivially modify main.go
You'll have this:
C:\>go build golang.org/x/build/version/go1.8.3

C:\>go1.8.3 version
go1.8.3: not downloaded. Run 'go1.8.3 download' to install to
C:\User\loggedinuser\sdk\go1.8.3

C:\>go1.8.3 download
Downloaded 0.0% (15233 / 83369649 bytes) ...

Downloaded 97.5% (81312629 / 83369649 bytes) ...
Downloaded 100.0% (83369649 / 83369649 bytes)
Unpacking C:\Users\loggedinuser\sdk\go1.8.3\go1.8.3.windows-386.zip ...
Success. You may now run 'go1.8.3'

C:\>go1.8.3 version
go version go1.8.3 windows/386


On Mon, Jun 26, 2017 at 8:41 PM,   wrote:
> You can also 'go get' most go versions and it's quite robust.
> https://twitter.com/golang/status/875117556595515392
>
>
> On Mon, Jun 26, 2017 at 5:17 PM, Igor Maznitsa  wrote:
>> mvn-golang plugin also allows to automate work with multiple versions of Go
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] add note to google groups golang-nuts introduction text

[fgergo]

If I understand correctly
https://groups.google.com/forum/#!forum/golang-nuts is usually the top
search result for "go mailing list" or similar queries.
I suggest adding something like this near the 4 listed rules:
"Please note: this is a google groups interface to a mailing list, you
can't delete the emails (>5k) your post generates."

On Fri, Jun 2, 2017 at 2:55 PM, Rudi  wrote:
> Well,  I deleted my original post before Ian replied because I anticipated
> his answer in advance.
...

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Embedded WebBroser

[fgergo]

Hi Jason,

 sorry about being slightly OT, though I've seen this on various other
lists recently: "...calling simple html and maybe java script?"

I'm curious, what do you mean when you write "calling html"? Which
mechanism or concept do you mean when "calling html"?

thanks,
Gergely Födémesi

On Fri, Dec 29, 2017 at 11:08 AM, Jason Petersson
 wrote:
> Hello is there a GitHub project or example of an application that can be
> built for calling simple html and maybe java script?
>
> Thank you,
> JNP
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] godoc.org graph default view shows huge graph even for smalli packages

[fgergo]

Hi,
 iirc earlier (years ago?) when on godoc.org I clicked "Package main
imports N packages (graph)" only non-standard dependencies were shown.
Now all dependencies are shown for the currently shown package graph.
When I click "Hide" on the graph page even then standard packges are
shown.
Do I remember correctly that the default graph view was more terse earlier?
Is this the intended behavior?
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Go fonts for linux (plan9port) acme?

[fgergo]

I know rog has already asked about this before and I am not sure if
it's feasible or not, but I ask, maybe someone has already thought of
a good resolution:

I'd like to use Go fonts on acme (plan9port linux), but fontsrv(4)'s
antialiased output is rather blurry at least compared to Windows'
Cleartype rendering.
(Without aa it's almost unreadable.)
(I don't have a mac, so I can't compare with acme (plan9port) on macos.)

How do you use Go fonts on linux?
or
Do you maybe have a nice 10 or 11 point version of Go proportional
fonts in font(7) format?
or
Can you maybe think of a vague draft how to generate these fonts on
windows using windows' Cleartype renderer?
or
Does acme on macos with Go fonts look ok? What's the difference?
Assuming fonts for acme are not fontsrv generated on macos, is there a
way to capture that output somehow and generate font(7) fonts?
or
Any other idea, how to have nicer Go proportional fonts for acme on linux?

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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go fonts for linux (plan9port) acme?

[fgergo]

On 10/13/18, Aram Hăvărneanu  wrote:
> Window's font rendering is simply wrong. Linux's is very similar to
> macOS's.
Do you mean anything else besides this?
https://www.joelonsoftware.com/2007/06/12/font-smoothing-anti-aliasing-and-sub-pixel-rendering/
Do you maybe have any objectively checkable arguments for or against
cleartype or for that matter for or against adobe style?

> I tried the Go fonts in acme, but reverted to Lucida Grande.
For me with fontsrv Lucida Grande looks more crisp than Go Regular as
well. Was that your reason for changing back or something else?
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

[fgergo]

On 10/19/18, Ian Lance Taylor  wrote:
> On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer 
> wrote:
>>
>> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor
>> wrote:
>>>
>>> The question is: is anybody actually doing this?  Is anybody seriously
>>> thinking about it?
>>
>> Unhelpfully, I imagine it unlikely that anyone distributing binary go
>> packages reads golang-dev or golang-nuts.
>
> Is there a more likely place to reach such people?
>
> Ian
>
If you plan to change during the next release maybe there is no better
place, although if the planned timeframe is 2-4 releases in the future
- maybe revisiting the "no warning" policy and a warning on planned
deprecation would be appropriate

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: do you use binary-only packages?

[fgergo]

On 10/19/18, Ian Lance Taylor  wrote:
> On Fri, Oct 19, 2018 at 1:14 AM, Sam Mortimer 
> wrote:
>>
>> On Thursday, October 18, 2018 at 4:28:23 PM UTC-7, Ian Lance Taylor
>> wrote:
>>>
>>> The question is: is anybody actually doing this?  Is anybody seriously
>>> thinking about it?
>>
>> Unhelpfully, I imagine it unlikely that anyone distributing binary go
>> packages reads golang-dev or golang-nuts.
>
> Is there a more likely place to reach such people?
>
> Ian
>
If you plan to change during the next release maybe there is no better
place, although if the planned timeframe is 2-4 releases in the future
- maybe revisiting the "no warning" policy and a warning on planned
deprecation would be appropriate

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Presidence of Operators

[fgergo]

Could you please give 2 examples, where the results depend on the
precedence? Maybe on play.golang.org ?
Maybe this also helps: https://golang.org/ref/spec#Operators

On 12/14/18, 伊藤和也  wrote:
> Can I say the precedence of paretheses are lower than unary operators and
> higher than binary operators.
> unary operators  (high)
>   ↑
>   parentheses ↑
> ↑
> binary operators  (low)
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Presidence of Operators

[fgergo]

(please reply to the list, so others with a similar question can find
this thread.)

I'm sorry, I should have made it clear: for me it's hard to parse the question.
I'll try again: could you please write 1 working example in
play.golang.org with the assumed precedence rules?
If you could share a link to that example in your reply, that would
help clarify the question. (Use the share button on play.golang.org to
show a link to be shared.)

On 12/14/18, 伊藤和也  wrote:
> OUnary operators have the highest precedence.
> According to go language specification, unary operators have the highest
> precedence means binary operators are the 2nd highest precedence maybe.
> and binary operators also have the precedence in 5 levels. When I use
> parentheses with unary operators, unary operators are evaluated first and
> when I use parentheses with binary operators,  parentheses are evaluated
> first.
> Example of parentheses with binary operators
>
> fmt.Println(false && (false || true))
>
> fmt.Println(false && false || true)
>
> There is no example of  parentheses with unary operators.
> Yes, parenthesis isn't an operator, it's a punctuation.
> So can I say the precedence of parethesis which is a parenthesis is lower
> than unary operators and
> higher than binary operators.
> unary operators  (high)
>↑
> parentheses   ↑
>↑
> binary operators  (low)
> 2018年12月14日(金) 19:15 :
>
>> Could you please give 2 examples, where the results depend on the
>> precedence? Maybe on play.golang.org ?
>> Maybe this also helps: https://golang.org/ref/spec#Operators
>>
>> On 12/14/18, 伊藤和也  wrote:
>> > Can I say the precedence of paretheses are lower than unary operators
>> > and
>> > higher than binary operators.
>> > unary operators  (high)
>> >   ↑
>> >   parentheses ↑
>> > ↑
>> > binary operators  (low)
>> >
>> > --
>> > 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.
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] I found a very strange code that would cause deadlocks and blocking，why???

[fgergo]

If you haven't studied concurrency before, I can't recommend any tutorials.
To start to learn about concurrency, I'd first recommend _some_
reading and theoretical background.

Concurrency is a complex concept. A "10x" multiplier estimation
compared to e.g. structured programming is probably right, definitely
not a 2x and probably not a 100x. Don't expect to become _proficient_
in concurrent programming in a couple of hours. Probably you won't be
able to download a couple of examples and start tinkering with them
successfully.

A good start is maybe:
https://golang.org/doc/faq#csp

Then maybe this:
https://en.wikipedia.org/wiki/Communicating_sequential_processes

The book is available for free:
http://www.usingcsp.com/cspbook.pdf

Don't expect to absorb the whole book in a couple of hours, it might
take from a couple of weeks to a few month to start to see how much
you still don't know.

As soon as you get a general understanding of concurrent concepts,
you'll most probably find adequate tutorials for yourself.

(To add to what Jan asked: for sharing code on golang-nuts please
share links to play.golang.org.)


On 3/1/19, mountain...@gmail.com  wrote:
> Is there a recommended tutorial?
>
> 在 2019年3月1日星期五 UTC+8下午12:21:58，Robert Engels写道：
>>
>> I think it would be helpful if you learned more about concurrent
>> programming. It is 10x harder, even with the simplifications that Go
>> offers. If you don’t understand the concepts you are going to struggle.
>> Start with some tutorials and work your way up.
>>
>> On Feb 28, 2019, at 10:14 PM, mount...@gmail.com  wrote:
>>
>> This is the stack information printed when blocking, how to see which G
>> blocking program?
>>
>> SIGABRT: abort
>> PC=0x7fff9ceabbf2 m=0 sigcode=0
>>
>> goroutine 0 [idle]:
>> runtime.pthread_cond_wait(0x1967620, 0x19675e0, 0x7fff)
>> /usr/local/go/src/runtime/sys_darwin.go:302 +0x51
>> runtime.semasleep(0x, 0x7fff5fbff670)
>> /usr/local/go/src/runtime/os_darwin.go:63 +0x85
>> runtime.notesleep(0x19673e0)
>> /usr/local/go/src/runtime/lock_sema.go:167 +0xe3
>> runtime.stoplockedm()
>> /usr/local/go/src/runtime/proc.go:2165 +0x8a
>> runtime.schedule()
>> /usr/local/go/src/runtime/proc.go:2565 +0x2d9
>> runtime.park_m(0xc72480)
>> /usr/local/go/src/runtime/proc.go:2676 +0xae
>> runtime.mcall(0x105722b)
>> /usr/local/go/src/runtime/asm_amd64.s:299 +0x5b
>>
>> goroutine 1 [semacquire]:
>> sync.runtime_Semacquire(0xc27794)
>> /usr/local/go/src/runtime/sema.go:56 +0x39
>> sync.(*WaitGroup).Wait(0xc27794)
>> /usr/local/go/src/sync/waitgroup.go:130 +0x64
>> cmd/go/internal/work.(*Builder).Do(0xc00023b0e0, 0xc0003ee3c0)
>> /usr/local/go/src/cmd/go/internal/work/exec.go:174 +0x38e
>> cmd/go/internal/run.runRun(0x195c300, 0xc1e0e0, 0x1, 0x1)
>> /usr/local/go/src/cmd/go/internal/run/run.go:137 +0x55b
>> main.main()
>> /usr/local/go/src/cmd/go/main.go:219 +0x7d4
>>
>> goroutine 5 [syscall]:
>> os/signal.signal_recv(0x0)
>> /usr/local/go/src/runtime/sigqueue.go:139 +0x9f
>> os/signal.loop()
>> /usr/local/go/src/os/signal/signal_unix.go:23 +0x22
>> created by os/signal.init.0
>> /usr/local/go/src/os/signal/signal_unix.go:29 +0x41
>>
>> goroutine 50 [select]:
>> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0,
>> 0xc0004b0620)
>> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
>> created by cmd/go/internal/work.(*Builder).Do
>> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>>
>> goroutine 51 [select]:
>> cmd/go/internal/work.(*Builder).Do.func2(0xc27794, 0xc00023b0e0,
>> 0xc0004b0620)
>> /usr/local/go/src/cmd/go/internal/work/exec.go:155 +0x12f
>> created by cmd/go/internal/work.(*Builder).Do
>> /usr/local/go/src/cmd/go/internal/work/exec.go:152 +0x36a
>>
>> goroutine 52 [syscall]:
>> syscall.Syscall6(0x7, 0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x0, 0x0,
>>
>> 0xc0002f43f0, 0x0, 0xce2400)
>> /usr/local/go/src/syscall/asm_darwin_amd64.s:41 +0x5
>> syscall.wait4(0x12006, 0xc50c24, 0x0, 0xc0002f43f0, 0x90, 0x1566d60,
>> 0x14cc401)
>> /usr/local/go/src/syscall/zsyscall_darwin_amd64.go:34 +0x7b
>> syscall.Wait4(0x12006, 0xc50c74, 0x0, 0xc0002f43f0, 0x0, 0x1, 0x1)
>> /usr/local/go/src/syscall/syscall_bsd.go:129 +0x51
>> os.(*Process).wait(0xc0002fd4a0, 0xc34a00, 0xc50cf8, 0x0)
>> /usr/local/go/src/os/exec_unix.go:38 +0x7b
>> os.(*Process).Wait(0xc0002fd4a0, 0x15b89c8, 0x15b89d0, 0x15b89c0)
>> /usr/local/go/src/os/exec.go:125 +0x2b
>> os/exec.(*Cmd).Wait(0xc00052da20, 0x0, 0x0)
>> /usr/local/go/src/os/exec/exec.go:465 +0x5b
>> os/exec.(*Cmd).Run(0xc00052da20, 0x50, 0xcdf7c0)
>> /usr/local/go/src/os/exec/exec.go:309 +0x5c
>> cmd/go/internal/base.RunStdin(0xcdf7c0, 0x1, 0x1)
>> /usr/local/go/src/cmd/go/internal/base/base.go:162 +0x11e
>> 

Re: [go-nuts] Re: why slice[len:len] okay, but slice[len] fail?

[fgergo]

Similar reason.

You might want to read about slices and arrays in go:
https://golang.org/doc/effective_go.html#slices

This might be helpful as well:
https://gobyexample.com/slices


On 3/8/19, Halbert.Collier Liu  wrote:
> Yes, i see,
> thank you so much!
>
> Could you please explain, why primes[6:6] okay, but primes[7:7] not?
> *:-)*
>
>
> 在 2019年3月7日星期四 UTC+8下午11:55:40，Robert Johnstone写道：
>>
>> Hello,
>>
>> When you use the colon, you taking a subset of the data.  Further, the
>> notation is a closed/open.  So a slice primes[6:6] is all of the element
>> in
>> the array with index >= 6 and index < 6, which is an empty set.  Note that
>>
>> the type of the expression primes[6:6] is []int.
>>
>> When you don't use the colon, you are access a specific element.  Since
>> the count is zero based, the valid indices are 0 through 5 inclusive.
>> Note
>> that the type of the expression primes[6] is simply int.
>>
>> Good luck.
>>
>>
>> On Thursday, 7 March 2019 10:32:04 UTC-5, Halbert.Collier Liu wrote:
>>>
>>> Hi.
>>>
>>> The code like below:
>>>
>>> package main
>>>
>>> import "fmt"
>>>
>>> func main() {
>>> primes := [6]int{2, 3, 5, 7, 11, 13}
>>> fmt.Println(primes[6:6]) .  // *OK*. return:   []
>>> //fmt.Println(primes[6]) .   // fail. out of bounds...
>>> }
>>>
>>> Why?
>>>
>>> Is the golang grammatical feature? or anything else..
>>>
>>> Any help, please!
>>>
>>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 2 generics counterproposal: giving up restricting types

[fgergo]

On 5/31/19, Nick Keets  wrote:
...
> This proposal is very interesting and seems to fit nicely into Go, with
> minimal disruption. And speaking personally, it would cover 99% of my needs
> for generics (I'm not that interested in Min/Max, but writing functions to
> get map keys gets old fast).
Interesting, could you please share the problems where the usual
iterating idiom is not good enough?

-- 
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%2Bctqro9o-RAa6QRVCEQ%2BPu_tre%2BCtJQZaP4LbBTB_6LQntWyg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] godoc(.org) query packages without cgo

[fgergo]

While browsing godoc.org for some functionality, I was wondering if
packages using cgo could be excluded from search results, like this:
"Hmm, I was wondering if godoc.org could show me packages with
"examplesearchterm" without cgo."

Did somebody look into implementing something like this earlier?

(Sometimes I would also like to exclude packages using package unsafe as well.)

I can imagine a more general search functionality, quering platform or
OS or minimal go version number or other "package context
dependencies" (what else?) would be useful as well.

If not godoc.org, does any other site implement similar search functionality?

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/CA%2BctqrqHGSZGW-3FELSZJV-ZGqaXqVg6CxA24%3D%3DQtJV8wGs%3DFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] why need "assist garbage collection" at a GC cycle? (runtime Code)

[fgergo]

Maybe the detail you are looking for is something like this:
https://blog.golang.org/ismmkeynote


On 6/6/19, ding liu  wrote:
> I cann`t find any infomation about "assist garbage collection" with google,
>
> so what`s the purpose of "assist garbage collection"?
>
> --
> 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/9f648a2f-33a2-4097-b503-35ba558f728e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Memory allocation question

[fgergo]

To share code please use Share on play.golang.org.
For the rest, please no screenshots, plain text is best.

On 6/6/19, Mark Bauermeister  wrote:
> Sorry in advance for the somewhat messy code, but this is something I've
> been trying to understand all day and can't quite come up with an
> explanation for.
> Basically, I wrote the below code to experiment with different data types
> and their impact on performance and memory efficiency.
>
> The code itself creates a map, an array, an empty slice and a slice already
>
> preallocated with the 1,000,000 required integers.
>
> Each data type is being filled with numbers ranging from 0 to 999,999, then
>
> I output the execution time ("latency") and the memory usage ("Heap" and
> "Stack").
>
> Now here is what I don't quite understand: Why would an array occupy more
> space on the heap and stack than a slice?
>
> Is there an issue in my code or the way I measure heap/stack allocation?
>
>
>
> [image: experiment.png] 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> package main
>
> import (
> "fmt"
> "sync"
> "time"
>
> "runtime"
>
> "github.com/fatih/color"
> )
>
> var mu sync.Mutex
> var mem runtime.MemStats
>
> func main() {
> imap()
> iarray()
> ipreSlice()
> islice()
> }
>
> func _green(text string) {
> fmt.Fprintf(color.Output, color.GreenString(text))
> fmt.Println()
> }
>
> func imap() {
> _green("Map Implementation")
> cache := make(map[int]int, 100)
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func iarray() {
> _green("Array Implementation")
> cache := [100]int{}
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func ipreSlice() {
> _green("Preallocated Slice Implementation")
> cache := make([]int, 100)
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache[i] = i
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func islice() {
> _green("Slice Implementation")
> cache := []int{}
> start := time.Now()
>
> for i := 0; i < 100; i++ {
> mu.Lock()
> cache = append(cache, i)
> mu.Unlock()
> }
> end := time.Since(start)
> fmt.Printf("Latency: %v \n", end)
>
> var sum int64
> for _, v := range cache {
> sum += int64(v)
> }
>
> fmt.Printf("Checksum: %v \n", sum)
> printHeap()
> printStack()
> }
>
> func printHeap() {
> runtime.ReadMemStats()
> fmt.Printf("Heap: %v MB", float64(mem.HeapInuse)/1024/1024)
> fmt.Println()
> }
>
> func printStack() {
> runtime.ReadMemStats()
> fmt.Printf("Stack: %v MB", float64(mem.StackInuse)/1024/1024)
> fmt.Println()
> fmt.Println()
> }
>
> --
> 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/07bc3bd3-8c9d-48d9-8a36-7e9e42d79637%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] where is the repository of proxy.golang.org?

[fgergo]

On Sat, Jun 15, 2019, 01:35 Abdullah Saleem  wrote:
>
> Asking the real question

I'm not sure what detail you are interested in. Geographically? Media?

Can you give an example answer for the same question for any other non
trivial url?

Maybe you are interested in this:
https://groups.google.com/forum/#!searchin/golang-dev/When$20will$20proxy.golang.org$20be$20opened$20sourced$20(if$20at$20all)$3F|sort:date/golang-dev/go6_lZqew6g/bhKMbhlFDQAJ

-- 
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%2Bctqro5E-%3Dak0uhwe58fVjJv%2BFpptznZH47OLB91j7oYdnCUw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could the go Tour be clearer on WHY recent make := zeroes

[fgergo]

On Thu, Jun 20, 2019, 18:56 Kevin Chadwick  wrote:

> Hi
>
> "https://tour.golang.org/moretypes/13;
>
> "The make function allocates a zeroed array and returns a slice that
> refers to
> that array."
>
> Yet more detailed literature states that make does not zero whilst new
> does.
>
> I gather this is because the shorthand used in the tour, instantiates new
> in the
> background and wants to be as simple as possible for new users?
>
> I am not sure if that is actually most helpful. To avoid confusion, should
> it be
> something like:
>
> The shorthand make := syntax allocates a zeroed array (akin to
> automatically
> invoking new) and returns a slice that refers to that array?
>
> Regards, Kc
>
> --
> 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/e045f1c3-782f-f733-73a0-16eccf908ef4%40gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

I'm not sure what you are asking for, but
the spec on initialization is quite clear:
https://golang.org/ref/spec#The_zero_value

I'm curious which detailed literature are you referring to?

>

-- 
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%2Bctqrr%3D5ThmWXBMTiprWpUwA9Rjs8SV%2BT_U83OYkQmPtBnj%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Could the go Tour be clearer on WHY recent make := zeroes

[fgergo]

(I forgot in my previous message: the email subject seems to imply
that := or make() was changed since 1.0. No it wasn't.)

This for later reference: new and make and initialization is very easy
to parse in the faq in the spec and in the effective go document:
https://golang.org/doc/faq#new_and_make

I'm not sure about the tour recommendation change, if you are curious
I recommend you to file an issue, to see what others with commit
rights think about the change.


On 6/20/19, Kevin Chadwick  wrote:
> On 6/20/19 8:30 PM, fge...@gmail.com wrote:
>> I'm not sure what you are asking for, but
>> the spec on initialization is quite clear:
>> https://golang.org/ref/spec#The_zero_value
>>
>> I'm curious which detailed literature are you referring to?
>
> I was prompted by atleast a couple of books but also the spec.
>
> Indeed the spec is clearer than I realised, had I clicked through on the
> link
> you sent "initial values", here.
>
> https://golang.org/ref/spec#Allocation
>
> Perhaps the tour could link to that section of the spec?
>
> https://tour.golang.org/moretypes/13
>
> "allocates a zeroed array" -> "https://golang.org/ref/spec#The_zero_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/982d264d-0e52-ad9e-775b-55172f06d29d%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] Re: constatnt conversion question

[fgergo]

I'm not sure if you are still interested in details or not.

Assuming you ask the question "why" it works differently, one of the
short answers, assuming some basic background knowledge on your part
about compilers and programming language implementation details:
similar, but different concepts->different restrictions->different
rules->different implementations.
You might want to take a look at the different precision requirements
in the spec for both constants and variables.
You maybe also want to think about the costs and benefits to having
the compiler and the compiled code work this way or if you are really
curious, think about how the same rules with the same semantics could
be implemented for both constants and variables,
I'm not sure, but iirc there was some discussion pre 1.0 about some of
the aspects of constants, you might want to take a look at the mailing
list archives.

Another short answer: the expressions just look similar, these aren't the same.

(+1: if you quote code, please use links to the playground or
alternatively just no html in emails.)


On 5/21/19, djad...@gmail.com  wrote:
>
> Thanks all for comments,
>
> for me confusion is that
> int( some_float_var)
>
> works, and surprisingly
> int( some_float_constant)
>
> does not.
>
>
> --
> 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/50e711ce-6e11-43d7-8e7f-46275e141bdb%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] constatnt conversion question

[fgergo]

Could you please clarify which statement your example is meant to
confirm or refute?



On 5/20/19, Michael Jones  wrote:
> ahem...
> https://play.golang.org/p/7gcb9Yv7c9e
>
> On Mon, May 20, 2019 at 2:45 AM  wrote:
>
>> https://golang.org/ref/spec#Constants
>>
>> "A constant may be given a type explicitly by a constant declaration
>> or conversion, or implicitly when used in a variable declaration or an
>> assignment or as an operand in an expression. It is an error if the
>> constant value cannot be represented as a value of the respective
>> type."
>>
>>
>>
>> On 5/20/19, djad...@gmail.com  wrote:
>> > Hi,
>> > does this should work ?
>> >
>> > package main
>> >
>> > import (
>> > "fmt"
>> > )
>> >
>> > func main() {
>> > const (
>> > c = 2
>> > z = 3.3
>> > y = c * z
>> > x = int(y) // or x int = y
>> > )
>> >
>> > fmt.Println(x)
>> > }
>> >
>> >
>> > it does not compile with error:
>> > constant 6.6 truncated to integer
>> >
>> > https://play.golang.org/p/f-Q6XSvvcrM
>> >
>> > --
>> > 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/736e8b03-d38f-4ec4-adc8-fcb77e0cda7b%40googlegroups.com
>> .
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bctqrp24YWs4cQVE2NxTEqzn0VxgRLTH3aAbXhjPKV21pDeqA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
>
> *Michael T. jonesmichael.jo...@gmail.com *
>

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

Re: [go-nuts] constatnt conversion question

[fgergo]

https://golang.org/ref/spec#Constants

"A constant may be given a type explicitly by a constant declaration
or conversion, or implicitly when used in a variable declaration or an
assignment or as an operand in an expression. It is an error if the
constant value cannot be represented as a value of the respective
type."



On 5/20/19, djad...@gmail.com  wrote:
> Hi,
> does this should work ?
>
> package main
>
> import (
> "fmt"
> )
>
> func main() {
> const (
> c = 2
> z = 3.3
> y = c * z
> x = int(y) // or x int = y
> )
>
> fmt.Println(x)
> }
>
>
> it does not compile with error:
> constant 6.6 truncated to integer
>
> https://play.golang.org/p/f-Q6XSvvcrM
>
> --
> 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/736e8b03-d38f-4ec4-adc8-fcb77e0cda7b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] constatnt conversion question

[fgergo]

naah, thanks, that's ok.
As soon as I can acquire my own turing machine, I'll insist on 1 number type.
Until then I can live with different number types and some rules for
my finite machines.


On 5/21/19, Michael Jones  wrote:
> Oh, Sorry. Have been away from email today. (Focused 100% in VS-code on a
> cool feature for Go)
>
> My statement was meant to convey an insight into a subtle aspect of Go's
> constants and high-precision expression evaluation--that the "type" of
> untyped constants/values, in the conversion rules sense, is derived in the
> instant of the conversion and is not an inherent trait of the value as is
> quite generally the case in other languages and situations. Also I think,
> the spec document is a little deceptive here, or at least, it needs to be
> read creatively to understand what all the possibilities are.
>
> In this case, the original question by Djadala was about a const "6.6" not
> being able to be coerced to integer form in either of two ways of
> trying ("x = int(y)" and "x int = y"). Both you and Jan explained why this
> is so and where/how it is defined in the specification. That was
> authoritative.
>
> However, the original question was worded in such a way that I could not
> discern if he was asking "please share the official reason why this seems
> impossible" or if instead he/she meant, "can I do this? I've tried two
> ways, and it seems impossible." I'm very supportive of the "how can I make
> it work?" sentiment and I doubted that the OP would figure it out since the
> two responses seemed so absolute, so I weighed in.
>
> Here's the subtle point. *That 6.6 constant "y" is NOT a floating-point
> value.*  it's value just happens to "be as if floating" at the moment.
> However, "y*10" evaluates to 66, and that is a "just plain 66" not "10
> times the floating point 6.6, therefore an inherent floating point value of
> 66.0" The upshot is that Djadala cannot get "y" into an int, but can easily
> get "10*y" into one, and having done so, can make that integer 66 into the
> integer 6 via truncating integer division as I showed in the linked Go
> Playground example: https://play.golang.org/p/7gcb9Yv7c9e
>
> Since the "6.6" has one decimal place making y *be as if floating point,*
> multiplication by an integer multiple of 10 is enough to clear the decimals
> and let it *be as if integer* in arbitrary expressions. If it was "6.67" (2
> places) or "6.678" (three places), then the least power of ten to clear the
> "as if floating" problem Djadala faced would be "10**k, k >= number of
> decimals" as was indicated in my comment in the linked Playground example.
>
> Sadly, this is not a general-purpose, remedy because the magic expression
> evaluation logic insists that values fit into the target size; were it not
> this way, we might imagine multiplying by 10**k, k>=19, capturing the
> integerness of the expression in that instant, and then dividing by the
> same factor. Alas, we'll be stopped right there because the expression,
> while *as if an integer,* is simultaneously, *as if too big to fit into
> one. *Since 64-bit ints are big and the OP was wrestling with only one
> decimal place in a small sized number, it worked with fifteen or more
> digits of precision to spare. However, if "y" were (1e16 + 0.6) then there
> would not be much wiggle room to clear the decimals this way.
>
> If these kinds of topics are interesting to you, there are discussions
> about related matters and possible changes for Go 2 in various proposal
> threads.
>
> On Mon, May 20, 2019 at 11:50 PM  wrote:
>
>> Could you please clarify which statement your example is meant to
>> confirm or refute?
>>
>>
>>
>> On 5/20/19, Michael Jones  wrote:
>> > ahem...
>> > https://play.golang.org/p/7gcb9Yv7c9e
>> >
>> > On Mon, May 20, 2019 at 2:45 AM  wrote:
>> >
>> >> https://golang.org/ref/spec#Constants
>> >>
>> >> "A constant may be given a type explicitly by a constant declaration
>> >> or conversion, or implicitly when used in a variable declaration or an
>> >> assignment or as an operand in an expression. It is an error if the
>> >> constant value cannot be represented as a value of the respective
>> >> type."
>> >>
>> >>
>> >>
>> >> On 5/20/19, djad...@gmail.com  wrote:
>> >> > Hi,
>> >> > does this should work ?
>> >> >
>> >> > package main
>> >> >
>> >> > import (
>> >> > "fmt"
>> >> > )
>> >> >
>> >> > func main() {
>> >> > const (
>> >> > c = 2
>> >> > z = 3.3
>> >> > y = c * z
>> >> > x = int(y) // or x int = y
>> >> > )
>> >> >
>> >> > fmt.Println(x)
>> >> > }
>> >> >
>> >> >
>> >> > it does not compile with error:
>> >> > constant 6.6 truncated to integer
>> >> >
>> >> > https://play.golang.org/p/f-Q6XSvvcrM
>> >> >
>> >> > --
>> >> > 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
>> >> > 

Re: [go-nuts] Does the code have any concurrent problem?

[fgergo]

Besides what others already suggested, you'll find the reason in the
Go memory model specification:
https://golang.org/ref/mem
This part is relevant here:
"If the effects of a goroutine must be observed by another goroutine,
use a synchronization mechanism such as a lock or channel
communication to establish a relative ordering."

+1:
Instead of html in email, please use only text. Although in this
particular case the playground links would have been just enough.
(If you are curious, my email reader renders the code text with light
yellow on white background. )

On 7/5/19, White Pure  wrote:
> Thanks for your reply.
> I've tried before and it reported race.
> But I don't understand why this code has race, and what's the possible bug?
> Here's the output:
> $ go run -race main.go
> ==
> WARNING: DATA RACE
> Write at 0x00c96000 by goroutine 7:
>   main.main.func3()
>   /Users/purewhite/go/src/xxx/main.go:26 +0x46
>
> Previous read at 0x00c96000 by goroutine 5:
>   sync/atomic.LoadInt32()
>   /usr/local/Cellar/go/1.12.6/libexec/src/runtime/race_amd64.s:206 +0xb
>   main.main.func1()
>   /Users/purewhite/go/src/xxx/main.go:13 +0x38
>
> Goroutine 7 (running) created at:
>   main.main()
>   /Users/purewhite/go/src/xxx/main.go:23 +0x115
>
> Goroutine 5 (running) created at:
>   main.main()
>   /Users/purewhite/go/src/xxx/main.go:11 +0xbd
> ==
> Found 1 data race(s)
> exit status 66
>
>
> 在 2019年7月5日星期五 UTC+8下午6:48:11，Andrew Pillar写道：
>>
>> Have you tried building with the -race flag?
>>
>>   go build - race
>>
>> This should help you figure out any data race conditions that may occur.
>>
>
> --
> 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/9c57fc61-141b-40b5-947a-5d7a3ad3547e%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [go-nuts] How to store the address of C struct on Go side in an array (cgo)

[fgergo]

On 7/13/19, Nitish Saboo  wrote:
> Hi Ian,
>
> Apologies for not being very descriptive with the issue.I will try to be
> more clear from next time.
> Can you please clarify the following that you had mentioned in the previous
> conversation of this email:
>
>> 3)Is it possible that one Go routine has already freed up the address
> that the other Go routine is trying to free  and that is causing this
> 'fatal error: bin/main': double free or corruption (fasttop)'
>
> Yes, that is possible.  It won't happen with the code I see above but
> I have no idea what the rest of your code is doing.
>
> How can it not happen with this particular code mentioned ?I did not
> understand this point.
> Can you please clarify this point ?
>
> Thans,
> Nitish
>
> On Fri, Jul 12, 2019 at 11:42 PM Ian Lance Taylor  wrote:
>
>> On Fri, Jul 12, 2019 at 10:53 AM Nitish Saboo 
>> wrote:
>> >
>> > Thanks for pointing it out.I am a beginner with Go and  CGO and have
>> never worked on corruption issues with C.
>> > I am familiar with python and Java.So just seeking help from the
>> > experts
>> to find the pain points that should be looked into.
>> > Hence, asking questions to Ian as in where all I should look for the
>> corruption issues.
>>
>> From my perspective, it's kind of like you have a broken clock, and
>> you are showing us a photo of the clock face, and asking how to fix
>> the clock.  We don't know.  The clock face looks OK.  The problem is
>> most likely inside the clock, but we can't see that.  Only you can see
>> that.
>>
>> Ian
>>
>
> --

Hi Nitish,
 you won't be able to get help, unless you show the code with the
reported behavior.

Please work on creating a small (<100 lines) self-contained,
executable reproduction case. That's most probably a significant
amount of work.
If this type of error happened to anybody else, he or she would have
to do this work him or herself as well. To be clear: that work must be
done. Without that there is no step 2 or better description or any
help.

The good news is that during that work, you might find the cause of
the error and even if not, you'll learn a lot about the environment
you are trying to create a program in.

When you are ready please share the result. Also please note that for
sharing code, links to gist.github.com or play.golang.org are
preferred.

Code snippets are not enough. Better descriptions are not enough.

Please don't ignore Ian's clock analogy, it's very good.

cheers

-- 
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%2Bctqrr6Wbw82QAFrLg-Gb9g%3DMi32uA9xt1otZW%3Ddv9y-KcoWg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] gc debug problem

[fgergo]

.On Wed, Aug 14, 2019, 17:56 sandao  wrote:

> type A struct {
> a int
> }
>
> func gen() []*A {
> r := make([]*A, 100)
> for i := 0; i < len(r); i++ {
> r[i] = {i}
> }
> return r
> }
>
> //var as []*A = gen()
>
> func main() {
> go func() {
> err := http.ListenAndServe(":8034", nil)
> if err != nil {
> //fmt.Printf("ListenAndServe:%s\n", err)
> }
> }()
> var as []*A = gen()
> fmt.Println(as[0])
> time.Sleep(100 * time.Second)
> }
>
> when debug gc:
> 1)if the "var as []*A = gen()"  is in main , the debug info is :  gc 4
> @2.757s 0%: 0.049+0.59+0.025 ms clock, 2.3+0/0.54/0.28+1.2 ms cpu,
> 16->16->0 MB, 31 MB goal, 48 P (forced)
> 2)if the "var as []*A = gen()"  is not in main, the debug info is: gc
> 9 @7.172s 0%: 0.077+25+0.020 ms clock, 3.7+0/24/0.73+0.99 ms cpu,
> 16->16->15 MB, 31 MB goal, 48 P (forced)
>
> Anybody konw why the mark time (red numbers) is so different?
>

when as is allocated on the stack, gc has a smaller task.


> --
> 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/e3a947ed-1a42-4d17-991d-d29cc80685e0%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/CA%2BctqrrGzQcP4txn4u4vD1c6uc6%2BksLZqR2eg_FOtznbYwp7XQ%40mail.gmail.com.

Re: [go-nuts] can someone guide me on where to share a few jobs available for GO-Lang Developers in CA?

[fgergo]

On Thu, Aug 15, 2019, 04:07 ARPwedding perrone 
wrote:

> I appreciate the guidance!  Thank you,  Olga Leon - ol...@jbcconnect.com
> - 212 355 3197
>

this list is fine.

>

-- 
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%2BctqrpfFYE2eJ1zh5%2BpuE-ObjprTBYU%3DanyZ9DXfB357s72%3DA%40mail.gmail.com.

Re: [go-nuts] gc debug problem

[fgergo]

On Thu, Aug 15, 2019, 05:19 sandao  wrote:

> In my opinion, the slice which "as"  point to, is all allocated on the
> heap in two case . so, I think the mark time should not be so different.
> Can you tell me more details for you answer(when as is allocated on the
> stack, gc has a smaller task.)?
>
> 在 2019年8月15日星期四 UTC+8上午11:02:46，Gergely Födémesi写道：
>>
>> .On Wed, Aug 14, 2019, 17:56 sandao  wrote:
>>
>>> type A struct {
>>> a int
>>> }
>>>
>>> func gen() []*A {
>>> r := make([]*A, 100)
>>> for i := 0; i < len(r); i++ {
>>> r[i] = {i}
>>> }
>>> return r
>>> }
>>>
>>> //var as []*A = gen()
>>>
>>> func main() {
>>> go func() {
>>> err := http.ListenAndServe(":8034", nil)
>>> if err != nil {
>>> //fmt.Printf("ListenAndServe:%s\n", err)
>>> }
>>> }()
>>> var as []*A = gen()
>>> fmt.Println(as[0])
>>> time.Sleep(100 * time.Second)
>>> }
>>>
>>> when debug gc:
>>> 1)if the "var as []*A = gen()"  is in main , the debug info is :  gc
>>> 4 @2.757s 0%: 0.049+0.59+0.025 ms clock, 2.3+0/0.54/0.28+1.2 ms cpu,
>>> 16->16->0 MB, 31 MB goal, 48 P (forced)
>>> 2)if the "var as []*A = gen()"  is not in main, the debug info
>>> is: gc 9 @7.172s 0%: 0.077+25+0.020 ms clock, 3.7+0/24/0.73+0.99 ms
>>> cpu, 16->16->15 MB, 31 MB goal, 48 P (forced)
>>>
>>> Anybody konw why the mark time (red numbers) is so different?
>>>
>>
>> when as is allocated on the stack, gc has a smaller task.
>>
>
see for yourself what the compiler says about that decision:
https://golang.org/cmd/compile/
you'll need -m

 you can also use pprof to check your assumptions.

(there isn't any computer near me currently)

-- 
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%2BctqrpTonR2GO8woPdCkr2Ta7BA262h4uSrqkUYvBFREGqQPw%40mail.gmail.com.

Re: [go-nuts] net library

[fgergo]

On Tue, Aug 20, 2019, 03:43 joe mcguckin 
wrote:

> I was perusing the NET library web page today.
>
> 1) Are the packages listed in any particular order?
>
> 2) What is the hierarchy? e.g., which functions correspond to the low
> level Unix network calls,
>  then there must be some higher level convenience functions. Is there
> a list of how the functions are ordered?
>

Could you please share the url you are interested in?

-- 
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%2BctqrrBJ0gVupcCu2ZEn9XYsRiYhUCe8pc2Q_FHRkip%3DSBvug%40mail.gmail.com.

Re: [go-nuts] "Go to" one line before the declaration

[fgergo]

The question is rather vague, though after making a few assumption
here are some hopefully useful pointers:

You can compare the different generated code snippets if you use -S
during compilation:
go tool compile -S mytestfile.go

A Quick Guide to Go's Assembler: https://golang.org/doc/asm
The go compilers implement this specification: https://golang.org/ref/spec

(Similary to Jan, for code please use only links to play.golang.org,
that's enough.)

hth


On 7/17/19, jessie.gocot...@rococoglobaltech.com
 wrote:
> Can somebody explain this code?
> How is the cpu doing? better than for{} and select {} in CPU usage?
>
> package main
>
> func main() {
> start:
> goto start
> }
>
>
> https://play.golang.org/p/BZ-yfDFLgV8
>
> --
> 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/17e87e55-5429-459d-8d68-66261c7d67dc%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

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

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.

[go-nuts] identify licences in a file tree?

[fgergo]

Hi,

 has anybody created a runnable utility - possibly using
github.com/google/licensecheck - to identify licences in a file tree?

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%2BctqrqT0631v6-HqY8UAo%3DAEScnrUfQsZwmb4TADFNPjNnOog%40mail.gmail.com.

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

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 

[go-nuts] ?import-graph on pkg.go.dev?

[fgergo]

Hi,
 is there a plan to be able to use ?import-graph on pkg.go.dev similar
to godoc.org in the future?
(Sorry if I missed any announcement about this.)
thanks,
Gergely Fodemesi

-- 
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%2Bctqrqg%3D-eoF1jnd6yP85S-reh7oaCNM%3DpPCE3LOYvyU4D5Gg%40mail.gmail.com.

Re: [go-nuts] gccgo problem compiling go from source

[fgergo]

On 10/20/20, gerritbinnenmars  wrote:
> Hello Ian,Thanks for the quick reaction. It seems my request was not
> clear.What I am doing is the other way around: using gccgo to build the "go"
> cmd.So clone the "go" source from github and then go build -compiler gccgo
> ./cmd/goGerrit

Assuming you are trying to get the compiler available on
github.com/golang/go (golang.org/dl) working on a hardware with ppc
e500 (en.wikipedia.org/wiki/PowerPC_e500) by cross compiling it with
gccgo running on linux/amd64, that won't work.

gccgo and github.com/golang/go are 2 different compilers running on
different hardware and os platforms, supporting different sets of
hardware and os platforms.

After looking at the list of supported platforms on build.golang.org
and looking at the golang-nuts and golang-dev mailing list archives, I
can't see the ppc e500 as a supported hardware platform for the go
compiler (available on golang.org/dl or github.com/golang/go  .)
Getting a compiler to support a new platform or porting a compiler to
a new platform are usually non-trivial processes.
At this stage you'll probably want to use the gccgo compiler if that's working.
(Also you'll maybe find this useful:
https://github.com/golang/go/wiki/PortingPolicy )

-- 
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%2Bctqrqy6AZd-U1VMu_Bd1Gf6amNo%2BBq3tcz_sjqudTRWqQMRg%40mail.gmail.com.

Re: [go-nuts] Re: module confusion

[fgergo]

On 8/15/20, Marvin Renich  wrote:
> * Volker Dobler  [200814 14:53]:
>> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
>> > Isn't this the default location?  I just untarred the distribution...
>>
>> No. There is a reason https://golang.org/doc/install#install
>> states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>

> It also might be productive to mention that many (Linux?) distributions
> (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
> Go, and that using the distribution's package manager may be easier,
> provide better security support, and integrate better than manually
> installing the official Go binary distribution.

Could you please give an example to "better security support" in a
distribution's package manager?

-- 
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%2BctqrqLaCVbHr8W4swdVZqd9hFNzEUDcdRh3yJopRhc_cxpng%40mail.gmail.com.

Re: [go-nuts] Re: module confusion

[fgergo]

On 8/17/20, 'K Richard Pixley' via golang-nuts
 wrote:
> On 8/15/20 00:43, fge...@gmail.com wrote:
>> On 8/15/20, Marvin Renich  wrote:
>>> * Volker Dobler  [200814 14:53]:
 On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
> Isn't this the default location?  I just untarred the distribution...
 No. There is a reason
 https://urldefense.com/v3/__https://golang.org/doc/install*install__;Iw!!NEt6yMaO-gk!R3z5eGP7tSVHh9dkw1eEv-l-WAko3RdxhuxICWySuRetk6bW0W3c9v5JhOxueCU2Ww$
 states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
>> 
>>> It also might be productive to mention that many (Linux?) distributions
>>> (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
>>> Go, and that using the distribution's package manager may be easier,
>>> provide better security support, and integrate better than manually
>>> installing the official Go binary distribution.
>> Could you please give an example to "better security support" in a
>> distribution's package manager?
> Part of the job of a distribution is integration.  Who owns which files,
> where they are stored, and who has access to them are all under the
> auspices of integration.  Go itself can't really be expected to manage
> all of those details for every single distribution that might ever
> exist.  But the local package manager can, and typically does both own
> and manage those details.

Oh but yes, I expect that the current Go installation scheme is
expected to manage all those details (a user's private namespace), so
it shall be a viable alternative for quite a long time.
(Although my imagination is limited, at the moment I can't imagine a
change where the all too frequent global namespace pollution of
operating system packages, which as I understand you can call
management if you like, would mess up the private namespace of a user
that much. At least for the mainstream desktop and server operating
systems.)

-- 
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%2BctqrpwaRji30_iZdff9qTU8foUvnDW%3D7yZr%3D-wJ5e_ACUXSQ%40mail.gmail.com.

Re: [go-nuts] Does golang uses copyOnWrite like java? where?

[fgergo]

Google copy on write go and you'll see the details. (The anwser is no.)
Also you might be interested in these:
https://golang.org/doc/faq#pass_by_value
https://golang.org/doc/faq#go_or_golang

(The faq is quite informative.)

cheers

On Tue, Jun 30, 2020, 06:15 刘骏龙  wrote:

> THX
>
> --
> 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/ba52a326-502e-4320-8573-efc7409ce773n%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/CA%2BctqrpNVGnMz8Q6P4Q-pwmMfi0m6Q%2Bv8psGpExP3Ae%3DpjDJxA%40mail.gmail.com.

Re: [go-nuts] How to determine system requirements for an application?

[fgergo]

If you can do that in any other language, similar strategy would work in
similar go programs as well.
(I assume you know you can't do that in the general case. For details see
the halting problem.)

On Fri, Jul 3, 2020, 11:58  wrote:

> Hello,
>
> If we make an application in golang then how to determine the system
> requirements required for its flawless execution.
>
> What are the parameters to justify the estimated values ​​of CPU and RAM,
> especially for the application.exe built in Golang
>
> 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/15d06b49-a467-4f5c-bd5c-c29c93b576d7o%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/CA%2Bctqrp%2B0J84-vM-7%3DRDEFZKYtQ7A7fV6haX%3DbPB1zA0xOrZFw%40mail.gmail.com.

Re: [go-nuts] go get golang.org/dl/go1.14.4 ?

[fgergo]

don't type 'type'.
go1.15beta1 is a new commands you'll have
in your system after you do 'go get go1.15beta1'.

then you need to do:
kpixley@kpixley-mbp> go1.15beta1 download
if this fails, check you $PATH if it includes the path to go1.15beta1
binary, if not add it to $PATH.


On 6/18/20, 'K Richard Pixley' via golang-nuts
 wrote:
> I must be missing something.  Could someone please point me?
>
> kpixley@kpixley-mbp> go version
> go version go1.14.4 darwin/amd64
> kpixley@kpixley-mbp> go get golang.org/dl/go1.14.4
> kpixley@kpixley-mbp> type go1.14.4
> bash: type: go1.14.4: not found
> kpixley@kpixley-mbp> go get golang.org/dl/go1.13.12
> kpixley@kpixley-mbp> type go1.13.12
> bash: type: go1.13.12: not found
> kpixley@kpixley-mbp> go get golang.org/dl/go1.15beta1
> kpixley@kpixley-mbp> type go1.15beta1
> bash: type: go1.15beta1: not found
>
> --
> 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/e4ec57c1-7234-457a-bdff-6448bcde0e34%40juniper.net.
>

-- 
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%2BctqrrfPuBbdBkmefm_Wh_FL%2BumUTG%3DUy9A0yd86s8od44efA%40mail.gmail.com.

Re: [go-nuts] Generic symbol metaproposal

[fgergo]

On Fri, Jul 24, 2020, 23:50 Ian Lance Taylor  wrote:

> On Fri, Jul 24, 2020 at 2:22 PM  wrote:
> >
> > On 7/23/20, Michael Jones  wrote:
> > ...
> > > Another delight is the uppercase signal for external.
> > >
> > > Maybe the “how to signal it” aspect of type instantiation could look to
> > > these approaches as well—make the automatic understanding so magical
> that
> > > the complete specification is unnecessary in most all cases, or the
> > > signaling so intrinsic to the variables that no identification Symbol
> or
> > > BracketedPair is necessary.
> >
> > Maybe braille?
> > ⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙
> > https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG
> >
> > ⠊⠞ ⠊⠎ ⠑⠁⠎⠽
>
> I've always felt that color is underused in modern programming languages.
>
> func Max(T)(s []T) T
>
> Ian
>

Who came up with the idea of "begin with Lu for exported symbols"? Maybe
there are other better ideas where that came from.

-- 
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%2BctqrqO%2ByYsW%3D%3D%3DQk87_%3D0qPiVmFTDyBgA4xyBdw6a95EpHYw%40mail.gmail.com.

Re: [go-nuts] Generic symbol metaproposal

[fgergo]

On 7/23/20, Michael Jones  wrote:
...
> Another delight is the uppercase signal for external.
>
> Maybe the “how to signal it” aspect of type instantiation could look to
> these approaches as well—make the automatic understanding so magical that
> the complete specification is unnecessary in most all cases, or the
> signaling so intrinsic to the variables that no identification Symbol or
> BracketedPair is necessary.

Maybe braille?
⠓⠑⠇⠇⠕⠺⠕⠗⠇⠙
https://www.royalblind.org/sites/www.royalblind.org/files/alphavet.PNG

⠊⠞ ⠊⠎ ⠑⠁⠎⠽

-- 
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%2BctqroajJ_JzGs5sAcmVOAjAPaaucRZsZ_XGqE%3DJV%2BbuuRTbw%40mail.gmail.com.

Re: [go-nuts] Re: module confusion

[fgergo]

On Sun, Aug 16, 2020, 04:42 Marvin Renich  wrote:

> * fge...@gmail.com  [200815 03:44]:
> > On 8/15/20, Marvin Renich  wrote:
> > > * Volker Dobler  [200814 14:53]:
> > >> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
> > >> > Isn't this the default location?  I just untarred the
> distribution...
> > >>
> > >> No. There is a reason https://golang.org/doc/install#install
> > >> states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> > >
> > 
> > > It also might be productive to mention that many (Linux?) distributions
> > > (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
> > > Go, and that using the distribution's package manager may be easier,
> > > provide better security support, and integrate better than manually
> > > installing the official Go binary distribution.
> >
> > Could you please give an example to "better security support" in a
> > distribution's package manager?
>
> The user can let the package manager automatically update packages with
> security fixes (at least in Debian) so the user doesn't have to stay on
> top of when a security update is available and manually reinstall the
> updated version of Go.  (Think of trying to do this individually for
> every piece of software installed on your system.)
>
> Perhaps "simpler" would have been a better word than "better".  One of
> the big reasons to use packages from a distribution rather than
> installing each one from source or from upstream's binary packages is to
> simplify system maintenance.
>
> ...Marvin
>

Let's just agree that the automated update scheme can be simple to some and
confusing to others.
Iirc that's one of the reasons why different package managers aren't
mentioned or supported.

If you search the list for earlier messages about the os provided package
management from a couple of years ago, you'll maybe find different reasons
as well.

-- 
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%2BctqrpOAEWbP9hcMKCP2%2B9sTEZS2gtzyuynbgUuav5dnL%3D6pw%40mail.gmail.com.

Re: [go-nuts] golang paths

[fgergo]

On 12/9/20, Dumitru Ungureanu  wrote:
> I decided to place them all in one place for containment.
Thanks! (Though I believe we can agree to disagree on the value of
this version of containment.)

> I used the names from envvars to get a simple answer to a simple question:
> *where is GOROOT?*, *in go/root*.
Interesting! I'm curious, what is the problem, when you need a
different answer other than "go env|grep GOROOT" ?

-- 
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%2BctqrpVUiZkON1jWbhtWOyY9tHgN4AcdZEu%3Ds7ea_8Rsw%3DR_w%40mail.gmail.com.

Re: [go-nuts] golang paths

[fgergo]

On 12/7/20, Dumitru Ungureanu  wrote:
...
> I'm currently using this directory tree for golang.
...
What do you mean when you write "golang"?

Why is https://golang.org/doc/install not good enough for the go compiler?

-- 
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%2Bctqrq67shAz8ao_XsfO6%2B1xkk76BGJh7vzGeiGXerXJaNoUQ%40mail.gmail.com.

Re: [go-nuts] golang paths

[fgergo]

On 12/8/20, Dumitru Ungureanu  wrote:
> Paths in symmetry with the environmental
> variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin. GOCACHE is
> go/cache, GOENV is go/env.
> Bonus points: modules in go/modules.

Why do you need to manage them explicitly? When do you need to look at
GOROOT, GOBIN, GOCACHE or GOENV?

(I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
After modules became the default, I've never set GOPATH either.)

>
> On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi wrote:
>
>> On 12/7/20, Dumitru Ungureanu  wrote:
>> ...
>> > I'm currently using this directory tree for golang.
>> ...
>> What do you mean when you write "golang"?
>>
>> Why is https://golang.org/doc/install not good enough for the go
>> compiler?
>>
>
> --
> 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/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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/CA%2BctqrqbJVbJn%2Bg%2B2b4VPvOmMB8iBdtrjW7hQz%2B08gRE4cUtRg%40mail.gmail.com.

Re: [go-nuts] golang paths

[fgergo]

There is no requirement to manage these variables or to know about them,
even if you don't use the installer.

I never use the installer and I've never needed to check on those
environment variables.

(The installation documentation is short and complete, maybe you should
check it out again.)

The installed go compiler is really just a trivial tree.

On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu  wrote:

> I don't use an installer. I set GOROOT/bin manually. And the rest follows.
> Easy to remember, nothing to forget.
>
> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
>
>> On 12/8/20, Dumitru Ungureanu  wrote:
>> > Paths in symmetry with the environmental
>> > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin.
>> GOCACHE is
>> > go/cache, GOENV is go/env.
>> > Bonus points: modules in go/modules.
>>
>> Why do you need to manage them explicitly? When do you need to look at
>> GOROOT, GOBIN, GOCACHE or GOENV?
>>
>> (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
>> After modules became the default, I've never set GOPATH either.)
>>
>> >
>> > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi
>> wrote:
>> >
>> >> On 12/7/20, Dumitru Ungureanu  wrote:
>> >> ...
>> >> > I'm currently using this directory tree for golang.
>> >> ...
>> >> What do you mean when you write "golang"?
>> >>
>> >> Why is https://golang.org/doc/install not good enough for the go
>> >> compiler?
>> >>
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to golang-nuts...@googlegroups.com.
>> > To view this discussion on the web visit
>> >
>> https://groups.google.com/d/msgid/golang-nuts/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%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/CA%2BctqroS22ktu%3DWMkMtFHmwjJ0dBk_fa_vmVQXGAXT1bQFFe9Q%40mail.gmail.com.

Re: [go-nuts] golang paths

[fgergo]

Sorry, I've lost it at "golang dev space", but I guess there could be
an explicit definition to that new phrase. (Though if that definition
is not used anywhere else, I can't see any value in that either.)
The directories exposed by the environment variables are not there to
be explicitly managed when doing go programming.
Most probably it's my lack of imagination, but after 11 emails I still
don't see the case where setting these variables has more value than
cost+risk.
That means I can't help with "Is there something I'm not taking into
consideration, maybe?". Best of luck!
cheers


On 12/9/20, Dumitru Ungureanu  wrote:
> Yes, you can safely assume we can agree to disagree on the value of my
> version for containment, no problem here :)
>
> My problem starts with the containment of the golang dev space for the
> user. Going from here, what dir names should I use? So I thought that using
>
> a dir tree based on envvars names should keep the confusion to a minimum.
>
> On Wednesday, December 9, 2020 at 10:04:48 AM UTC+2 Gergely Födémesi wrote:
>
>> On 12/9/20, Dumitru Ungureanu  wrote:
>> > I decided to place them all in one place for containment.
>> Thanks! (Though I believe we can agree to disagree on the value of
>> this version of containment.)
>>
>> > I used the names from envvars to get a simple answer to a simple
>> question:
>> > *where is GOROOT?*, *in go/root*.
>> Interesting! I'm curious, what is the problem, when you need a
>> different answer other than "go env|grep GOROOT" ?
>>
>
> --
> 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/b272eef9-f0d0-40d1-8a15-f92ca89e976bn%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/CA%2BctqroVQLcAK1FMxPEJ5KB5D7WwjXan69q6zUjo2DH7z%2Bk4Yw%40mail.gmail.com.

Re: [go-nuts] golang paths

[fgergo]

To clarify the go compiler toolchain is a trivial tree. Compared to
most other mainstream languages and compilers, it's not scattered to
different subtrees. I believe quite some effort went into that to stay
that way.
When using the go compiler toolchain some directories are used for
caching compiler artifacts. (You could easily delete all of these
files between compiling sessions, you'll still be able to compile
everything again. Though only a very space constrained environment
would require such a peculiar workflow.)

If you are a go programmer the subtrees you set explicitly are 100%
managed by the toolchain, there is no _need_ to ever look at them.
Please note, that if you set them explicitly and with that you
inadvertently mix and match different versions of go toolchain
binaries and cached artifacts you'll most probably run into issues you
don't want to have.

Sure the environment variables can be set differently, if you have
special requirements (maybe you don't have enough space on the same
device). Sorry I wasn't clear: I tried to ask for these special
requirements.
To rephrase and clarify my original question: besides "Paths in
symmetry with the environmental variables" why is it valuable to
rearrange the subtrees for your use case? What are your
requirements/issues you came up with a solution for?

To help with your original question, assuming your only goal is to
manage all subtrees exposed by environment variables "go env" shows at
least 3 more trees you might want to set (GOMODCACHE, GOTOOLDIR,
GOTMPDIR.)



On 12/9/20, Dumitru Ungureanu  wrote:
> Yes, there is no requirement to manage the envvars. I personally believe
> there is a requirement to know about them, though.
> I read the installation doc, I think there's a hang up on your part on this
>
> one.
> The default go tree is scattered different places, beside the obvious
> trivial tree you're mentioning.
> I'm arranging all the paths in a single place and I harmonize the paths
> with the envvars.
> Maybe you're missing the whole point I'm making in this blog post?
> https://mitflit.ro/blog/golang-paths-of-mitflit/
>
> On Tuesday, December 8, 2020 at 10:47:27 PM UTC+2 Gergely Födémesi wrote:
>
>> There is no requirement to manage these variables or to know about them,
>> even if you don't use the installer.
>>
>> I never use the installer and I've never needed to check on those
>> environment variables.
>>
>> (The installation documentation is short and complete, maybe you should
>> check it out again.)
>>
>> The installed go compiler is really just a trivial tree.
>>
>> On Tue, Dec 8, 2020, 17:38 Dumitru Ungureanu  wrote:
>>
>>> I don't use an installer. I set GOROOT/bin manually. And the rest
>>> follows. Easy to remember, nothing to forget.
>>>
>>> On Tuesday, December 8, 2020 at 6:28:50 PM UTC+2 Gergely Födémesi wrote:
>>>
 On 12/8/20, Dumitru Ungureanu  wrote:
 > Paths in symmetry with the environmental
 > variables: GOROOT is go/root, GOPATH is go/path, GOBIN is go/bin.
 GOCACHE is
 > go/cache, GOENV is go/env.
 > Bonus points: modules in go/modules.

 Why do you need to manage them explicitly? When do you need to look at
 GOROOT, GOBIN, GOCACHE or GOENV?

 (I've never set or checked GOROOT, GOBIN, GOCACHE or GOENV explicitly.
 After modules became the default, I've never set GOPATH either.)

 >
 > On Tuesday, December 8, 2020 at 4:45:06 PM UTC+2 Gergely Födémesi
 wrote:
 >
 >> On 12/7/20, Dumitru Ungureanu  wrote:
 >> ...
 >> > I'm currently using this directory tree for golang.
 >> ...
 >> What do you mean when you write "golang"?
 >>
 >> Why is https://golang.org/doc/install not good enough for the go
 >> compiler?
 >>
 >
 > --
 > You received this message because you are subscribed to the Google
 Groups
 > "golang-nuts" group.
 > To unsubscribe from this group and stop receiving emails from it, send
 >
 an
 > email to golang-nuts...@googlegroups.com.
 > To view this discussion on the web visit
 >
 https://groups.google.com/d/msgid/golang-nuts/f5c636d8-97e3-4fc1-a28f-d5cc93a0fa52n%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...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/86ab9747-9c2c-4f91-9980-6d00b3a3af13n%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 

[go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

[fgergo]

Sorry I forgot 1 more expectation/boundary condition: I'd like to be
able to tar both go code in the local filesystem and the referenced go
packages in the local filesystem and copy it to a different OS to
different absolute paths?
I believe I can't use replace?


On 3/24/21, fge...@gmail.com  wrote:
> Assuming GO111MODULE=on, if I don't want to publish anything and I
> only want to build go code in the local filesystem, referencing only
> go packages in the local filesystem.
>
> Can I do that without local version control software and a private module
> proxy?
>
> After reading most module documentation on golang.org, I still can't
> answer this question.
> If anybody already does that, could you please share your setup?
> If a local version control and a private module proxy is needed, could
> you also please share the details?
>
> 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/CA%2Bctqroy91XgrtAXN_kf%2B7xJZy1zmXJ8v4eADjcDDv5DSEHS0Q%40mail.gmail.com.

[go-nuts] what is a minimal setup for compiling go programs in module mode?

[fgergo]

Assuming GO111MODULE=on, if I don't want to publish anything and I
only want to build go code in the local filesystem, referencing only
go packages in the local filesystem.

Can I do that without local version control software and a private module proxy?

After reading most module documentation on golang.org, I still can't
answer this question.
If anybody already does that, could you please share your setup?
If a local version control and a private module proxy is needed, could
you also please share the details?

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/CA%2Bctqron2z0tRfO1jtkurfmc_CXOogG9o4d28g%2Bfg8WaXH6wkw%40mail.gmail.com.

Re: [go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

[fgergo]

Thanks, that's exactly what I was looking for!

For the next go programmer looking for a solution in similar situation:
on page https://golang.org/ref/mod#vendoring
"... or to ensure that all files used for a build are stored in a
single file tree"



On 3/24/21, Miguel Angel Rivera Notararigo  wrote:
> You can use the vendor folder, just copy (or symlink, but you will need to
> keep them updated) what you need there and will work.
>

-- 
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%2BctqrrSX%3DSi0iqRwBKrr0pSz_yd2n6by9RrowfwicBKMoCbjg%40mail.gmail.com.

Re: [go-nuts] Re: what is a minimal setup for compiling go programs in module mode?

[fgergo]

Thanks to both you and jake!
I remembered something similar to "import path should not be relative
paths". (Otoh the replace directive is not an import path, so I should
have checked before asking this.)
Anyways, thanks again!



On 3/24/21, Amnon  wrote:
> You can just tar up your ~/go/pkg/mod directory (plus your own sources) and
>
> you will be good.
>
> On Wednesday, 24 March 2021 at 16:19:13 UTC jake...@gmail.com wrote:
>
>> > I believe I can't use replace?
>>
>> I'm glad the vendoring solution is what you want. But IIUC what you are
>> trying to do, then there is no reason you can not use replace. For
>> example:
>> require gergrly/otherpackage v0.0.0
>> replace  gergrly/otherpackage => ../otherpackage
>> This works for me. You could then tar, the outer folder.
>>
>>
>>
>
> --
> 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/03ecf1f1-7441-41cc-8e76-6049d62e3dccn%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/CA%2BctqrrKjTrcoKeKjGsPzQcppk2BLvUXhCWANWZ4x3%3D7NtDjiQ%40mail.gmail.com.

[go-nuts] getting-started page instructions unclear

[fgergo]

On page https://golang.org/doc/tutorial/getting-started#call :
step 1.3. : visit https://pkg.go.dev/rsc.io/quote#pkg-index
step 1.4. instructs "At the top of this page, note that package quote
is included in the rsc.io/quote module."

How can I "note that package quote is included in the rsc.io/quote module." ?
Which part of "the top of this page" on page
ttps://pkg.go.dev/rsc.io/quote#pkg-index describes the "included"
relation?

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/CA%2Bctqrpk0gznYXO8WqWp%3D1sxGnJNVz8v8KAWCSSZFFcuT-_WmQ%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Thank you both, for sharing your thoughts on this!

On 3/30/21, 'Axel Wagner' via golang-nuts  wrote:
> Again: I understand what you are asking for and I'm not saying there is no
> benefit.
>
> Personally, I don't feel the benefit is very large and I don't think it's
> worth it. You might very well think it is and that's fine. As i said in my
> first message, if anyone feels this is important to have, my suggestion is
> to search github for an existing issue about this (I would not be surprised
> if there is one) and filing one if there are none.
>
> I don't think there is anything else to discuss in this thread - IMO all
> the information is here. Either you think it's a good idea, or you don't.
>
> --
> 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/CAEkBMfEk4FQovmMhgYVY2cgrGRPJPPmDNqCMa33%3DNhW%2BTC_vnw%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%2Bctqrq9VY%3D_eB6YhGon8ok7RzuZyULw22b65mETvkAJhr2vFw%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Thanks, fully agree on everything.

Please consider this workflow:
1. find package on pkg.go.dev (currently there is no build constraint
specific information listed beside the result, cf. issue #39195)
2. get package (go get, git clone, cp etc.)
3. "build constraints exclude all Go files in ..."
4. wat? (pkg.go.dev did not "promise" this)
5. let's visit _each_file manually (or try to grep for some hints) to
try to identify all failing build constraints and think about how to
satisfy them or give up failing.

Please also note, if step 1 or 2 or 3 provided more information on
build constraints, the failing step 3 wouldn't be surprising. Now it
is and I believe some tooling support (either in step 1, 2 or 3) would
be helpful.

(I agree the answer to "what build tags must be set for a file to
build" is NP complete.)

An "explanation" like I described in my 2nd email would be very
helpful and that isn't more complex than P. (If it is, please provide
a hint.)

Or even just the identified and relevant build constraints in CNF is
most probably enough to take a look at and go like nah, I can see
buildconstraintX and buildconstraintY, I can give up _quickly_ and not
waste _more_ time trying to get the package to build.

If you agree the workflow above is not ideal, what do you think about
the "build constraint explanation" or the build constraints in CNF?

On 3/29/21, Axel Wagner  wrote:
> FWIW, you might be assuming that a build tag always has the form `// +build
> linux` or `// +build !cgo` - in which case it's indeed clear what the
> "correct" answer is and how to determine it. But you can't assume that
> build tags only take that form, you can express *any* boolean formula,
> using any amount of variables with them.
>
> On Mon, Mar 29, 2021 at 12:47 PM Axel Wagner
> 
> wrote:
>
>> I might not understand what you are intending.
>>
>> My understanding is that you want, given a set of .go files, know "why"
>> they are excluded. Which, to me, means finding a configuration of build
>> tags that would allow at least one of them to be built. A file can be
>> built
>> with a set of tags, if the boolean formula expressed by the build
>> constraints  evaluates
>> to true. Therefore, determining why a file is excluded by a set of build
>> tags is the boolean assignability problem.
>>
>> It is trivial, given a set of build tags, to find out if a given file
>> builds. So, it is easy to say "this file does not build given the build
>> tags I have". But it's NP-complete, to find out what build tags must be
>> set
>> for a file to build. So it's hard to say "this file does not build, but
>> it
>> *would* if I changed the build tags to that".
>>
>> It's even harder to determine what the "intuitively right" answer is. For
>> example, a package might require cgo when built on Windows/arm, but not
>> when built on Linux/amd64. So both the answer "you need cgo" and the
>> answer
>> "you need to amd64" would be correct, if you are trying to build on
>> Windows/arm and it's not obvious which is correct. Or, a more trivial
>> example: What about a build tag like `// +build foo,!foo`? Should the
>> report say `foo` has to be set, or that it has to not be set, or do we
>> need
>> additional logic to detect cases like this?
>>
>> Again, none of this means we can't do *something*. But without a clear,
>> efficient algorithm and without an obviously correct answer to
>> ambiguities,
>> we'd first have to decide on what we'd specifically like to do :)
>>
>> On Mon, Mar 29, 2021 at 12:29 PM  wrote:
>>
>>> Thanks for thinking about the issue!
>>> I should have asked for something more explicit, probably something like
>>> this:
>>> ; go build listconstraintexclusions
>>> buildconstraint_1 excludes:
>>> file1.go
>>> file2.go
>>> file3.go
>>> buildconstraint_2 excludes:
>>> file4.go
>>> file5.go
>>> No go files left to build.
>>> ;
>>>
>>> Iiuc the complexity of creating this list is in P.
>>> (I understand my original question was different.)
>>>
>>>
>>> On 3/29/21, Axel Wagner  wrote:
>>> > In general, answering that question is NP-complete. It's the boolean
>>> > satisfiability
>>> > problem
>>> > .
>>> It
>>> > would be possible to implement *some* solution and maybe stop after a
>>> > timeout or something. But even then, the answer will not be unique and
>>> > might sometimes be less than helpful.
>>> >
>>> > This doesn't mean we *can't* do it, but the problem is harder than it
>>> might
>>> > seem. You could file an issue (after searching if someone else
>>> suggested it
>>> > already, of course :) ).
>>> >
>>> > On Mon, Mar 29, 2021 at 10:49 AM  wrote:
>>> >
>>> >> Is there some functionality to list each build constraint that is not
>>> >> satisfied when the result of go get is "build constraints exclude all
>>> >> Go files in ..."?
>>> >>
>>> >> go mod why is very helpful when module dependencies are to be
>>> explained.
>>> 

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Thanks for thinking about the issue!
I should have asked for something more explicit, probably something like this:
; go build listconstraintexclusions
buildconstraint_1 excludes:
file1.go
file2.go
file3.go
buildconstraint_2 excludes:
file4.go
file5.go
No go files left to build.
;

Iiuc the complexity of creating this list is in P.
(I understand my original question was different.)


On 3/29/21, Axel Wagner  wrote:
> In general, answering that question is NP-complete. It's the boolean
> satisfiability
> problem . It
> would be possible to implement *some* solution and maybe stop after a
> timeout or something. But even then, the answer will not be unique and
> might sometimes be less than helpful.
>
> This doesn't mean we *can't* do it, but the problem is harder than it might
> seem. You could file an issue (after searching if someone else suggested it
> already, of course :) ).
>
> On Mon, Mar 29, 2021 at 10:49 AM  wrote:
>
>> Is there some functionality to list each build constraint that is not
>> satisfied when the result of go get is "build constraints exclude all
>> Go files in ..."?
>>
>> go mod why is very helpful when module dependencies are to be explained.
>> A similar functionality would be helpful and maybe a message to refer
>> to this functionality when "build constraints exclude all Go files in
>> ..." is the conclusion.
>>
>> (For a random package I've found on pkg.go.dev it took a few confusing
>> minutes until I realized that cgo requirement is the build
>> constraint.)
>>
>> On a tangential note: would anybody else be interested to help with
>> issue https://github.com/golang/go/issues/39195 ? (Probably all build
>> constraints should be searchable.)
>>
>> --
>> 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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%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%2BctqrrBXbCkJSnTLHYggTv8k%2BhJ6FgDnun%3DFrYNRoM6kCKx2w%40mail.gmail.com.

[go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

Is there some functionality to list each build constraint that is not
satisfied when the result of go get is "build constraints exclude all
Go files in ..."?

go mod why is very helpful when module dependencies are to be explained.
A similar functionality would be helpful and maybe a message to refer
to this functionality when "build constraints exclude all Go files in
..." is the conclusion.

(For a random package I've found on pkg.go.dev it took a few confusing
minutes until I realized that cgo requirement is the build
constraint.)

On a tangential note: would anybody else be interested to help with
issue https://github.com/golang/go/issues/39195 ? (Probably all build
constraints should be searchable.)

-- 
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%2Bctqrq1%2BSVDQO3ecgyj7Kq4Qv6-tE3QWFTrVHtNqro8hUCwCw%40mail.gmail.com.

[go-nuts] go mod vendor, description, how?

[fgergo]

Hi,

 assuming GO111MODULE=on.
I don't want to publish anything, anywhere.

Beside the main package, I want to put functionality into other new
packages as well.
Could somebody share the workflow to do _only_ that?
Where can I read about the correct incantations?

To organize the source files on
https://golang.org/ref/mod#go-mod-vendor this is not enough
information for me:
"The go mod vendor command constructs a directory named vendor in the
main module's root directory that contains copies of all packages
needed to support builds and tests of packages in the main module. "

How, does the "go mod vendor" command construct the vendor directory?
Where does it copy the files from?
How is the copy instructed (what to copy, what not to copy)?

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

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

On 3/29/21, Axel Wagner  wrote:
> On Mon, Mar 29, 2021 at 2:57 PM  wrote:
...
> An "explanation" like I described in my 2nd email would be very
>> helpful and that isn't more complex than P. (If it is, please provide
>> a hint.)
>>
>
> I still don't understand how you think we should provide this explanation
> without solving SAT.
> For example, you write
>
> buildconstraint_1 excludes:
> file1.go
> file2.go
> file3.go
>
> What is "builtconstraint_1" and how is it determined by the go tool? My
> first impression was that it is supposed to be a build tag (like "cgo"),
> which opens up the problems I asked - it's not clear which tag is "at
> fault" or how to figure that out.
I assumed (ha!) buildconstraint_1 as a parsed predicate (e.g. "//
+build linux") would be helpful. In a more complex case it isn't.
Thanks again!

>
> Or even just the identified and relevant build constraints in CNF is
>> most probably enough to take a look at and go like nah, I can see
>> buildconstraintX and buildconstraintY, I can give up _quickly_ and not
>> waste _more_ time trying to get the package to build.
>>
>
> Sure. That's certainly easy enough to do. FWIW, currently you can get an
> approximation of that via
>
> grep -R "// +build" .
>
> After #41184  that would give an
> even clearer result, as the build constraints are actually guaranteed to be
> in DNF with at most one line per file (AIUI).
>
> It is certainly possible to build a version of this into the Go tool for go
> 1.17 already. That is, we could build in a command that just recursively
> looks for and parses build constraints and prints them out per-file in CNF
> or DNF. Personally, I feel like I would rarely use it though, because I'd
> find just a plain grep easier to remember, given that I use it daily. But
> my personal feelings shouldn't deter you from proposing this :)
agreed :)

Still the experience is very much non-go like, though with such a
power build constraint language it'll stay like that.

-- 
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%2Bctqrps942fEXSJF_LvJ11FWoQD%3DExkV-nqUr6pHyZDwYoYDw%40mail.gmail.com.

Re: [go-nuts] explain functionality similar to "go mod why for" to help with message "build constraints exclude all Go files in ..." ?

[fgergo]

On Mon, Mar 29, 2021, 17:46 Wojciech S. Czarnecki  wrote:

> Dnia 2021-03-29, o godz. 15:17:42
> "'Axel Wagner' via golang-nuts"  napisał(a):
>
> > I still don't understand how you think we should provide this
> explanation without solving SAT.
> ...
> > What is "builtconstraint_1" and how is it determined by the go tool? My
> > first impression was that it is supposed to be a build tag (like "cgo"),
> > which opens up the problems I asked - it's not clear which tag is "at
> > fault" or how to figure that out.
>
> As I understood the OP, it would be nice to have build -n and -v messaging
> us
> with short info about the constraint that excluded given file from under
> build.
>
> And I concur.
>

Since the build constraint language is equivalent to a first order logic
language, no guaranteed useful information can be provided in the general
case in a limited time.
I also thought that predicates would be useful, but only the terms in a
normal form could be useful, but that would provide - most probably - "too
much".

grep should be good enough :)

-- 
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%2BctqrrA32J2UhZYoQL5qsJ4Op3UXFaPZQfv1%3DwjgYJ3QkeXaw%40mail.gmail.com.

Re: [go-nuts] Re: go mod vendor, description, how?

[fgergo]

On 4/6/21, Volker Dobler  wrote:
> Probably you are overthinking it.
> ...

Thank you all for your replies!
I did overthink.

When https://blog.golang.org/using-go-modules [part1-5] were
published, I've read all of them, some parts several times. It helped
with code migrations.
Still my question remains: assuming almost exactly a decade of using
go with GOPATH how should have I found the information in your
replies?

+1 question: what's the thing with the dot requirement in the module
path? It's probably not a requirement, but than again, why is it
casually mentioned in some module relevant replies?

I know good terse documentation is much harder to write, than a good
complete documentation. I've tried to read https://golang.org/ref/mod
(~24k words), but I was not strong enough and gave up. The go
programming language specification is ~28k words, I've read it a few
times.

Are we trying the document similar complexity? If yes, I believe this
has implications for the future use of modules, if no, there is room
for improvement. What do you think?

Thanks again for your time!

-- 
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%2BctqrosXn1PhdudK1HNGJEeOS8F0EaEuKfC_VA4pnBRRArOsQ%40mail.gmail.com.

Re: [go-nuts] Can I play with go1.18 beta while keeping my stable 1.17 version around for production code?

[fgergo]

Sure:
https://go.dev/doc/manage-install#installing-multiple



On 12/15/21, Travis Keep  wrote:
> This may be silly question, but is there a way for me to download and play
> with 1.18 while keeping my existing 1.17 installation for production code?
>
> Is there a way to have multiple versions of go installed on the same
> computer?
>
> --
> 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/d4b079cb-4830-4103-8267-7787294af8b2n%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/CA%2BctqrpT7pXRZJaUdXcMgJwCM%2BPOsW5oqyyNxbiy5Svz1VAhbA%40mail.gmail.com.

Re: [go-nuts] Mathematical operations - the generics way

[fgergo]

some details: https://github.com/golang/go/issues/48918

On 3/18/22, Endre Simo  wrote:
> Now that generics are officially supported, I was checking in the Go source
>
> if there are some generic implementation of utility methods like Abs, Min,
> Max etc, but I couldn't find it other than this
> proposal https://github.com/golang/go/discussions/48287.
>
> Anyone knows if something related has been adopted and implemented in Go
> 1.18?
>
> --
> 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/e930b89a-0ba6-46f5-b3ec-7aeb26d8acf9n%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/CA%2BctqrpxUm7tPnSkh4rEH%3DCut4RUzX2A-%2BmS96FwVXGuZN7Fdg%40mail.gmail.com.

Re: [go-nuts] behaviour (issue) of time.Ticker microsecond duration ticks

[fgergo]

On 1/31/22, envee  wrote:
> Hi All,
> I understand this issue has been discussed in the past, and I have seen a
> few comments from Ian and Russ Cox about this topic, but I could not arrive
>
> at a conclusion about how I can make the time.Ticker send me ticks at
> atleast close to the Ticker duration I specify. At the moment, I am seeing
> ticks being sent at way over the specified duration especially when I have
> sub-millisecond durations.
> With 1ms duration, the ticker seems to be quite close to the duration
> (maybe within +/-5%). I would be happier if it were within 1%, but I can
> handle that.
>
> With 1 micro-second duration, the ticker sends ticks nearly 4 times slower
> than expected.
>
> Here is my sample code
> "
> ti := time.NewTicker(1 * time.Millisecond)
> start := time.Now()
> for i := 0; i < 1000; i++ {
> <-ti.C
> }
> fmt.Printf("elapsed time = %v\n", time.Since(start))
> "
>
> The output is usually close to 1 second as expected (close to) when using
> 1ms duration.
> elapsed time = 1.000159338s
>
> But when I change the Ticker duration to 1 micro-second, I get the
> following output which shows the elapsed time close to 4 seconds:
> elapsed time = 4.796662856s
> *Is there anyway, I can ensure ticks are sent at approximately within 5% of
>
> my specified duration ?*
>
> I understand from time.Ticker docs that ticks will be lost if the ticker
> handler cannot keep up with the ticker time.
>
> In the simple code above, I am literally doing very minimal work in each
> loop iteration and that is about checking the loop condition.
> So I am not sure why ticks are being lost ?
The answer probably depends on what you are interested in:
Why ~2000 cycles is not enough for scheduling the loop or
could ~2000 cycles be enough for scheduling the loop?
What do you think should happen if you change time.Microsecond to
time.Nanosecond?

-- 
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%2BctqrrDVq4HFgXOMdOV%2Bfuu1svr6yAXFcDOFeYhXhRc2x_PRg%40mail.gmail.com.

Re: [go-nuts] Re: DataRace with slice, should i fix it or ignore it?

[fgergo]

If the updated "go/benign-race link" is a canonical url, could you
please share the prefix as well?
( I tried http://go.dev/go/benign-race and some other variations, but
these don't work. Archive.org link is working. )

On 2/10/22, 'Dmitry Vyukov' via golang-nuts
 wrote:
> I've recovered it and updated the go/benign-race link.
>
> On Thu, 10 Feb 2022 at 18:35, Ian Lance Taylor  wrote:
>>
>> [ + dvyukov ]
>>
>> On Thu, Feb 10, 2022 at 9:16 AM jake...@gmail.com 
>> wrote:
>> >
>> >
>> > On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote:
>> >>
>> >> Pelen Li,
>> >>
>> >> Always fix your data races. You should consider the results of data
>> >> races as undefined.
>> >>
>> >> Dmitry Vyukov, who implemented the Go race detector, once wrote an
>> >> interesting article with the title: "Benign data races: what could
>> >> possibly go wrong?"
>> >>
>> >> https://twitter.com/dvyukov/status/288858957827682304
>> >
>> >
>> > This article by Dmitry Vyukov was an "oldie but goodie". I have used it
>> > as reference in these kinds of discussions before. Unfortunately,
>> > AFAICT, the article is no longer available on Intel's site. I have been
>> > unable to locate an alternate location. If anyone knows where I can find
>> > it, I would appreciate the info.
>
> --
> 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/CACT4Y%2BbWWEHRrK3hvMd0ndSE%3DcdyfhN8gyCYRBfuc6-xJSsSfg%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%2BctqrqmcSxRcwq89sn2nTpd%2BCchWTv8_4Rcw2ounhW5PTKGeQ%40mail.gmail.com.

Re: [go-nuts] Re: Best coding practice for resiliient client-server communications

[fgergo]

In case you're interested in details of github.com/rogpeppe/retry :
https://www.youtube.com/watch?v=yZTEAXdcuH4

On 5/25/22, Tamás Gulácsi  wrote:
> I bet on https://pkg.go.dev/github.com/rogpeppe/retry - it allows a simple
>
> for iter := strategy.Start(); iter.Next(ctx.Done()); {
>   if err := todo(ctx); err == nil {
> break
>   } else if permanent(err) {
> break
>   }
> }
>
> portt...@gmail.com a következőt írta (2022. május 25., szerda, 16:02:16
> UTC+2):
>
>> This was an interesting read:
>>
>> "Timeouts, retries, and backoff with jitter"
>>
>> https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/
>>
>> I wonder what is a good practice in Go code to retry/reconnect/recover but
>>
>> not too aggressively, when connections fail or are stalling or choppy?
>> (Not
>> really AWS specific...)
>>
>>
>>
>
> --
> 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/119cbaba-d3b7-4cc0-b1b5-7d86c71bcf7bn%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/CA%2Bctqro%2BWMGKpg2nNR%2BXxCg2CRpct47ghZJM-%3Dx7e8XiqfC9Uw%40mail.gmail.com.

Re: [go-nuts] Clarification of memory model behavior within a single goroutine

[fgergo]

On 1/23/23, Peter Rabbitson  wrote:
...
> I guess I will spend some time to learn how to poke around the generated
> assembly tomorrow...

If I understand correctly you are trying to force your model of the
world into the Go memory model. The models are different, so this
won't work.

Please also note that your model of current execution complexes is
probably valid today, but it could change anytime. The Go memory model
is differently restricting to accommodate for that future.

Of course you can implement what you want using any tool available,
but the correct execution can't be ensured by the Go memory model if
you don't build on that.

-- 
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%2BctqrpxFc0htmyO3ApMtLWMKdyig-Eoay0x%2BnU1sO8Lmmw2hA%40mail.gmail.com.

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime?

[fgergo]

On 1/29/23, bobj...@gmail.com  wrote:
> I'm glad to see this issue getting some discussion. I have 100+ smallish
> utility programs written in Go, and each one consumes about 1.5 MB (precise
>
> average: 1,867,844 bytes); my bin directory contains 100+ copies of the Go
> runtime. Sadly, I mainly use Windows, and there seems to be no way to use
> linked libraries in Go for Windows.
>
> My solution has been to rewrite many of my smallish Go programs in Python
> (except those that really need Go's speed)  -- 10K each vs. 1.5M each disk
> storage.
...
I've seen similar reasoning before, hence my question: can you share
some details about your windows environment where ~150MB difference
for 100+ programs in storage needs is noticeable?
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/CA%2Bctqrr%2BiphompR47BZU%3D39V1O-Vr_geSYemQcm6kYTLfM_Kdg%40mail.gmail.com.

[go-nuts] Re: [golang-dev] Importing .xls and .xlsx files with golang.

[fgergo]

(golang-...@googlegroups.com is for developing the Go language
(bcc-d), you'll want to use golang-nuts@googlegroups.com, now on cc.)

If I understand correctly, you plan to parse excel files. I haven't
tried these just yet, but maybe search on
https://pkg.go.dev/search?q=xls

best,
fgergo

On 2/8/23, Aadi Sharma  wrote:
> Can we  import the files with extension *.xls* and *.xlsx*, such as we
> import *.csv* files with golang.
>
> --
> 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/2c6ee11f-e948-4854-ac91-8709bb9ef9fcn%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/CA%2Bctqrqkq0ZA3NCd3_21VfZt5B_w5kQfpj8dc2XHzW31oryggw%40mail.gmail.com.

[go-nuts] snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

[fgergo]

C *nprintf(3) implementations stop the conversion when n is reached.
I couldn't find a similar functionality in the standard library, what
did I miss?
If there isn't any, any idea how to implement that without
reimplementing all format helpers?
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/CA%2BctqroOignMzqDar4Vq9k_B3f6N%2B5BnDhvggwkdczh%2BeT_irQ%40mail.gmail.com.

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

[fgergo]

On Tue, Feb 6, 2024 at 12:18 PM 'Brian Candler' via golang-nuts
 wrote:
>
> The C functions are mainly there to prevent overrunning already-allocated 
> buffers, which isn't an issue with Go.
Thanks! In addition to that, It also helps with code with upper limit
memory-requirement, which fmt.Sprintf() can't.
Though I can live with careful coding and not using Sprintf() in this
case, I just hoped possibly somebody else already thought about
needing that.

...
> You could make a custom type which implements io.Writer and truncates at a 
> given size, and pass it to fmt.Fprintf
IIUC this sounds similar to what I'm asking for. How to use a limiting
io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
memory usage?

-- 
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%2Bctqro%3D9St0Qj_A-UGEUowvjK1OHX%3DQJ2QiBAMQdxZBwvHM%2Bw%40mail.gmail.com.

Re: [go-nuts] Re: snprintf() in Go with at most constant memory requirement difference than snprintf(3)?

[fgergo]

(This time reply to list. Sorry Brian.)

On Tue, Feb 6, 2024 at 3:03 PM 'Brian Candler' via golang-nuts
 wrote:
>
> > Thanks! In addition to that, It also helps with code with upper limit
> > memory-requirement, which fmt.Sprintf() can't.
>
> If you're processing data from untrusted sources, then you probably ought to 
> validate it first.
>
> > How to use a limiting
> > io.Writer with fmt.Sprintf()? How would this limit fmt.Sprintf()'s
> > memory usage?
>
> Proof-of-concept: https://go.dev/play/p/kJabvvTzFH0
>
> I don't know under what circumstances this would cause Fprintf to terminate 
> early; it depends on how much buffering it does internally. I would guess 
> that a large single argument like "%s" would be treated as a single entity, 
> and very likely allocate an intermediate buffer of the full size.
>
> If this matters in your use case, then I think you shouldn't be using Sprintf 
> and friends.
I should probably limit memory usage outside of the process anyway.
A bit unexpected, though I'm not complaining.
cheers

-- 
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%2BctqrraLr%3Dh%2BXuPGOzgfu%3DQD0O_abqMm4bSX6LPPPtGMxwejA%40mail.gmail.com.

[go-nuts] go build ./... vs. go install ./...

[fgergo]

What's the reason for these 2 command to behave differently regarding
producing binaries?
Serious question for additional points: produce a string to search for
./... on the web, in gmail or on github. Afaict ellipsis won't help
here.
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/CA%2BctqrpuURxEEC4Lnbuq%3DniLheGC5agvXC2fVQHj9yXuwJ9f3Q%40mail.gmail.com.