[go-nuts] Re: Allocating lots (e.g. a million) objects on the heap

[jake...@gmail.com]

Do the data structures contain pointers? If not, I seem to strongly recall 
that the GC does not have to scan slices when the objects contain no 
pointers. Perhaps someone with in-depth knowledge of the GC can confirm or 
refute that. If that is the case, then large slices should not be a burden 
on the GC, and would be the simplest solution. 

On Monday, July 20, 2020 at 1:35:14 PM UTC-4 netconn...@gmail.com wrote:

> I have an application where I will be allocating millions of data 
> structures, all of the same size. My program will need to run continuously 
> and be pretty responsive to 
> its network peers.
>
> The data is fairly static, once allocated it will rarely need to be 
> modified or deleted.
>
> In order to minimize the garbage collection scanning overhead, I was 
> thinking of allocating large blocks on the heap that were a fixed size that 
> would hold 20K or so elements
> and then write a simple allocator to hand out pieces of those blocks when 
> needed. Instead of having to scan millions of items on the heap, the GC 
> would only be scanning 100 or so
> items.
>
> Sound reasonable?  Or does this 'go' against the golang way of doing 
> things?
>
> F
>

-- 
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/30026832-81de-44ff-8796-2f3534e23bffn%40googlegroups.com.

[go-nuts] Re: Generics and parentheses

[jake...@gmail.com]

Presumably the instantiation of generic types and functions will be a lot 
more common than the declarations. How does your proposal handle those?

(FWIW, I'm fine with square brackets, or really anything other than parens.)

On Monday, July 20, 2020 at 12:42:13 PM UTC-4 Geoff Speicher wrote:

> This is great work but compared to the rest of Go's existing syntax, I 
> personally find it much harder to grok the generic code examples regardless 
> of bracket choice.
>
> It seems like a lot of complication stems from what effectively amounts to 
> requiring the programmer to declare a new generic type everyplace one is 
> needed. This seems like a lot of unnecessary noise, especially when you 
> consider that a package is likely to reuse generic types.
>
> What if we were to require (or at least allow/encourage) declaration of 
> any generic types at the package level? Then any function or type is itself 
> generic by virtue of whether or not it uses any generic types.
>
> So instead of:
>
> // existing proposal requires additional (type T)
> // syntax for type parameter declaration
> func Print(type T)(s []T) {
> for _, v := range s {
> fmt.Println(v)
> }
> }
>
> We would have:
>
> // declare a new package-level type, similar to "type T" but using
> // a new keyword to indicate that it is generic
> generic T
>
> // Print is a generic function because T is a generic type
> func Print(s []T) {
> for _, v := range s {
> fmt.Println(v)
> }
> }
>
> The keyword generic indicates a generic type declaration, and since the 
> Print function uses the generic type T, we know that Print is a generic 
> function. We don't need any additional syntax at the site of the function 
> definition. Type constraints can appear within the type declaration just as 
> they do in the existing proposal's "inline" generic declaration.
>
> By encouraging reuse of the generic declaration, this approach also 
> encourages better choice of generic type naming instead of the ubiquitous 
> T which is used almost exclusively for its brevity in inline generic type 
> parameter declarations. For example:
>
> // declare a generic type with constraint of Stringer.
> // the name "Stringable" conveys more meaning than "T".
> generic Stringable Stringer
>
> // type definition requires no extra syntax for a generic type 
> parameter
> type StringableVector []Stringable
>
> // method definition requires no extra syntax for a generic type 
> parameter
> func (s StringableVector) String() string {
> var sb strings.Builder
> for i, v := range s {
> if i > 0 {
> sb.WriteString(", ")
> }
> // It's OK to call v.String here because v is of 
> generic type Stringable
> // and Stringable's constraint is Stringer.
> sb.WriteString(v.String())
> }
> return sb.String()
> }
>
> I don't know how this affects your implementation, but it certainly 
> reduces the need for many parser changes, and eliminates the need for extra 
> brackets in favor of a new keyword. It's also much easier for my aging eyes 
> to read. ;)
>
> Geoff
>
>

-- 
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/7ad301de-fe8d-4b8c-886f-7d86f8fec4d2n%40googlegroups.com.

[go-nuts] Re: minimum linux kernel version that can run latest golang

[jake...@gmail.com]

See the list in https://golang.org/doc/install

On Saturday, July 25, 2020 at 1:31:07 AM UTC-4 cuiw...@gmail.com wrote:

> what is the minimum version of linux kernel that can run golang?

-- 
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/c747189f-9865-43c2-a58e-c36e769a2410n%40googlegroups.com.

Re: [go-nuts] import a file

[jake...@gmail.com]

On Tuesday, July 28, 2020 at 11:21:38 PM UTC-4 Kurtis Rader wrote:

> See https://golang.org/ref/spec#Import_declarations. By default importing 
> a package requires using the package name to refer to any symbols it 
> exports; e.g., "jsonstuff.Prices". You can do "import . jsonstuff" to allow 
> accessing its public symbols without qualification. Google "go import 
> unqualified" for some discussions about the pros and cons of unqualified 
> imports.
>

As a beginner, please don't use the "." imports. It is very non-standard 
and bad form in all but a few specific cases.  Start good habits early. The 
correct eay to reference prices is "jsonstuff.Prices"

-- 
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/8afd146f-92ed-4dce-a9a2-f05c0d5d6794n%40googlegroups.com.

Re: [go-nuts] builtin function definitions

[jake...@gmail.com]

The good news is that Go is simpler than many other languages, with fewer 
constructs, concepts and corner cases. So after using it for a while, you 
will rarely bump into anything "new". 
Reading the language spec is great, and I have done it myself a couple of 
times. But, depending on your level of programming experience, it may be a 
bit difficult to pull useful information from the spec, and can be a bit 
tedious to read. For starters, I strongly suggest working through A Tour of 
Go , maybe a few times. It covers almost 
all the language concepts. Type switches are covered in in the tour at: 
https://tour.golang.org/methods/16.

On Wednesday, July 29, 2020 at 5:21:23 PM UTC-4 shan...@gmail.com wrote:

>
>
> On Wednesday, July 29, 2020 at 7:23:22 PM UTC+10, mb0 wrote:
>>
>> This is a special kind of switch called a type switch. You can read more 
>> about it in the language specification where its part of the intrinsic 
>> go syntax. https://golang.org/ref/spec#Switch_statements 
>>
>> Because it is a special language construct you need to look at the 
>> compiler. You probably want to check out the default gc compiler and may 
>> start your journey here: 
>>
>> https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/swt.go#L617
>>  
>>
>> This is really helpful, thanks.
>
> The two questions I am left with are:
> How do I recognise that something is a "special language construct"; is it 
> simply a matter of, I cannot ctrl-] to it directly, so I need to grep?
>
>
> And, just as importantly, how do I find out what I need to grep /for/
>
> Regards
>  
>

-- 
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/81b3fbee-9628-4571-9816-c1df299671ebn%40googlegroups.com.

[go-nuts] Re: Newbie question about type-casts

[jake...@gmail.com]

There is probably a better way, but lets start with a clear definition of 
the problem. Your post says you want to "round *down*" but the variable 
'bet' is the result of a divide by 4, rounded *up*. Which do you actually 
want to do?

On Sunday, August 2, 2020 at 5:09:45 PM UTC-4 traxp...@gmail.com wrote:

> I have written my first little piece of Go-code.
> However it took some time and code for me to divide a int64 by 4 and round 
> down. 
>
> How can the last two lines be rewritten?
>
> Regards
> Martin
>
> package main
>
> import (
> "fmt"
> "bufio"
> "math"
> )
>
>
> var cash int64
> scanner := bufio.NewScanner(os.Stdin)
>
> scanner.Scan()
> cash,err = strconv.ParseInt(scanner.Text(), 10, 64)
> if err != nil {
> fmt.Println(err)
> }
>
> var bet int64
> bet = int64(math.Ceil(float64(cash)/float64(4)))
> cash = cash - bet
>
>
>
>

-- 
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/9858e40e-454e-4700-8556-83f5e3c0ec08n%40googlegroups.com.

[go-nuts] Re: Is there a gui library for Go, like Gtk+ or similar, which can be used to build statically linked executables ?

[jake...@gmail.com]

There is currently no 'clear choice' for GUI in go. It will depend on you 
needs. Some to look into:

https://bitbucket.org/rj/goey/src/master/
https://gioui.org/
https://github.com/andlabs/ui
https://github.com/goki/gi
https://github.com/lxn/walk

On Sunday, August 2, 2020 at 11:53:32 AM UTC-4 Serge Hulne wrote:

> Is there a gui library for Go, like Gtk+ or similar, which will produce a 
> statically linked executable ?
>
> The aim is to create apps which do not require the user to install GTK or 
> any extra libraries in order to use the app.
>
>
>

-- 
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/8963e9bd-5a2a-4f42-9664-6adec0d7d744n%40googlegroups.com.

[go-nuts] Re: How to fast transpose byte matrix [][]byte in Golang assembly

[jake...@gmail.com]

Not a direct answer, but one simple improvement you could do is to allocate 
all the rows together, then break them up by slicing. So instead of your:

T := make([][]byte, n)
for i := 0; i < n; i++ {
T[i] = make([]byte, m)
}

Do something like:

T := make([][]byte, n)
Q := make([]byte, m*n)
for i := 0; i < n; i++ {
T[i] = Q[i*m : (i+1)*m] 
}

In my benchmarks, with your matrix size, this gives a 20-30 percent 
speedup. In part because it avoids many allocations, but also (I suspect) 
because the data is contiguous.  

On Wednesday, August 5, 2020 at 2:30:28 PM UTC-4 shenw...@gmail.com wrote:

> Hi all,
>
> Matrix transpose in pure golang is slow in HPC cases, and using package 
> gonum needs structure transformation which costs extra time. So a 
> assembly version may be a better solution.
>
> Sizes of the matrix vary ([][]byte) or can be fixed for example (
> [64][512]byte), and the element type may be int32 or int64 for general 
> scenarios.
>
> Below is a golang version:
>
> m := 64
> n := 512
>
> // orignial matrix
> M := make([][]byte, m)
> for i := 0; i < m; i++ {
> M[i] = make([]byte, n)
> }
>
> func transpose(M [][]byte) [][]byte {
> m := len(M)
> n := len(M[0])
>
> // transposed matrix
> T := make([][]byte, n)
> for i := 0; i < n; i++ {
> T[i] = make([]byte, m)
> }
>
> var row []byte // a row in T
> for i := 0; i < n; i++ {
> row = T[i]
> for j = 0; j < m; j++ {
> row[j] = M[j][i]
> }
> }
>
> return 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/d7e20ba9-df02-42cc-859d-653450b48e1bn%40googlegroups.com.

[go-nuts] Re: [ generics ] Added constraint type inference to the design draft

[jake...@gmail.com]

Am I correct in thinking this has NOT been added to the go2go playground 
yet? 
When I try the example it fails: https://go2goplay.golang.org/p/TiMsP2K_3DS
Or am I making some stupid mistake?

On Wednesday, August 12, 2020 at 10:31:51 PM UTC-4 Ian Lance Taylor wrote:

> I just added a new section to the generics design draft describing
> constraint type inference. This is a generalization and
> simplification of the earlier pointer method approach, which has now
> been removed. I would be happy to hear any comments. Thanks.
>
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>
> Ian
>

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

[go-nuts] Re: Go Benchmarks And Escape Analysis

[jake...@gmail.com]

 0.00429 ns/op seems suspiciously low. I suspect that there could be a 
problem with your benchmark. Could you post the code. 
( On this mailing list please just send code as plain text or as a link to 
the Go playground.) 

On Thursday, August 13, 2020 at 9:18:52 PM UTC-4 Patrick wrote:

> I'm new to go, and have being looking at escape analysis by benchmarking 
> some code that I created.
>
> What I see is the escape analysis shows that certain variables escape to 
> the heap.
>
> parameter path leaks to {heap} with derefs=2
>
>
> But the result of the benchmark test shows 0 allocations.
>
> 10  0.00429 ns/op0 B/op0 allocs/op
>
>
> Does the 0 allocs/op mean that the compiler optimised the code and the 
> parameter path did not leak to the heap?  Also, since there are 0 
> allocs/ops does this mean I don't need to be concerned about leaking to the 
> heap?
>
> Allocation recording is turned on in the test
>
> 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/082e063f-e297-4eca-97bb-2c4f5f8a658an%40googlegroups.com.

[go-nuts] Re: Windows 'Access is denied' for os.Remove after exec.Output()

[jake...@gmail.com]

This works fine for me on Windows 10. 
What is "my.exe" doing? 
Do you have third party antivirus software? If so, try turning it off. They 
are notorious for causing this kind of problem. 

On Friday, August 14, 2020 at 5:02:36 AM UTC-4 atakanc...@gmail.com wrote:

> Hello dear fellow gophers, 
>
> I had a relatively simple yet quite inconvenient issue which I felt the 
> need to ask here. In my main() function;
>
> os.Remove("my.exe") // err is nil, my.exe is removed
>
> works in Windows without any errors, but when I call exec beforehand, I 
> get access is denied error;
>
> buffer, err := exec.Command("my.exe", myArgs...).Output() // err is nil 
> here, I get desired output
> os.Remove("my.exe") // remove "C:\\...\my.exe": Access is denied
>
> I tried using cmd.Process.Kill(), cmd.Process.Wait(), 
> cmd.Start()-ioutil.ReadlAll()-cmd.Wait() alternatives as well. I kept 
> getting no errors until 'Access is denied'. 
>
> I'm using go1.14 linux/amd64 for my compiler and Windows 10 Enterprise 
> 10.0.18362.
>
> Thank you.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4f4f3cb1-3aa0-40cb-81fb-78eee2c4e172n%40googlegroups.com.

[go-nuts] Re: Windows 'Access is denied' for os.Remove after exec.Output()

[jake...@gmail.com]

> Turns out it takes some time to release the lock on the folder, so we 
should do some time.Sleep before the os.Remove, so that Windows can release 
the lock.  

I do not believe that should be the case under normal Windows operation. 
Using a Sleep in a case like this is always a hack. Sometimes it is the 
only way, but it can fail randomly, especially under stress. There is 
likely something else going on. Could be poorly written antivirus software, 
or a finalizer that has not run in your go app, or something else. If it is 
ok for it to work "most of the time", then maybe your Sleep() solution is 
sufficient. But if you need real reliability, I suggest figuring out what 
is really going on. 

On Friday, August 14, 2020 at 10:10:44 AM UTC-4 atakanc...@gmail.com wrote:

> Hello guys, I have solved the issue.
>
> Turns out it takes some time to release the lock on the folder, so we 
> should do some time.Sleep before the os.Remove, so that Windows can release 
> the lock. 
>
> Thank you both for replying.
>
> 14 Ağustos 2020 Cuma tarihinde saat 16:21:17 UTC+3 itibarıyla 
> jake...@gmail.com şunları yazdı:
>
>> This works fine for me on Windows 10. 
>> What is "my.exe" doing? 
>> Do you have third party antivirus software? If so, try turning it off. 
>> They are notorious for causing this kind of problem. 
>>
>> On Friday, August 14, 2020 at 5:02:36 AM UTC-4 atakanc...@gmail.com 
>> wrote:
>>
>>> Hello dear fellow gophers, 
>>>
>>> I had a relatively simple yet quite inconvenient issue which I felt the 
>>> need to ask here. In my main() function;
>>>
>>> os.Remove("my.exe") // err is nil, my.exe is removed
>>>
>>> works in Windows without any errors, but when I call exec beforehand, I 
>>> get access is denied error;
>>>
>>> buffer, err := exec.Command("my.exe", myArgs...).Output() // err is nil 
>>> here, I get desired output
>>> os.Remove("my.exe") // remove "C:\\...\my.exe": Access is denied
>>>
>>> I tried using cmd.Process.Kill(), cmd.Process.Wait(), 
>>> cmd.Start()-ioutil.ReadlAll()-cmd.Wait() alternatives as well. I kept 
>>> getting no errors until 'Access is denied'. 
>>>
>>> I'm using go1.14 linux/amd64 for my compiler and Windows 10 Enterprise 
>>> 10.0.18362.
>>>
>>> Thank you.
>>>
>>

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

Re: [go-nuts] map without default values

[jake...@gmail.com]

On Friday, August 14, 2020 at 2:52:20 PM UTC-4 Joe Marty wrote:

>
>> If I know that a value exists, or am fine using the zero value (again, 
>> that's the majority of my personal use-cases for maps at least), having to 
>> use a statement just to discard the extra bool is annoying.
>>
>   
> Right, so this brings me back to a nice solution to both our use cases, 
> which would be to initialize the map as either having a default or not 
> having a default.  You don't have to check for failure, I don't have to 
> worry about forgetting to check for failure... right? :D
>
 
I know they are not here yet, but this is the kind of thing that generics 
were intended for. Once we have generics, you will be free to create a type 
safe map wrapper that gives you whatever behavior you want. IIRC, a richer 
set of containers is one of the main reasons people want generics in go. 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/eb65af00-7805-4bf5-87b1-d41c9f0e7e6bn%40googlegroups.com.

[go-nuts] [generics] Constraint type inference not working

[jake...@gmail.com]

When I try the example from the "Constraint type inference" section of the 
Draft Design: 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
 
it does not seem to actually work:

https://go2goplay.golang.org/p/pfq3QV6gdgf

What am I missing?

-- 
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/3bbfb679-c1fe-4179-bfb4-17e127d8ee2cn%40googlegroups.com.

[go-nuts] Re: What does "ex-wait-release" mean?

[jake...@gmail.com]

See https://groups.google.com/g/golang-dev/c/qtxOW0x4Rrw/m/WqepX5V6AQAJ on 
the golang-dev forum. It mean that it was wait-release but the tree is now 
open for development. 

On Monday, August 17, 2020 at 3:23:55 AM UTC-4 lziq...@gmail.com wrote:

> Some of my CLs are tagged with this, and I don't know why? Can someone 
> please tell me?
>
> https://go-review.googlesource.com/c/go/+/244778  
>

-- 
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/b47fc560-836c-4fd6-8336-1e3d9f99ac6fn%40googlegroups.com.

Re: [go-nuts] Memory synchronization by channel operations and mutexes

[jake...@gmail.com]

On Monday, August 17, 2020 at 11:19:16 AM UTC-4 b.ca...@pobox.com wrote:

> On Monday, 17 August 2020 11:54:55 UTC+1, leo.b...@npo-data.nl wrote:
>>
>> E.g. A co-worker pointed out that you can avoid sync.Mutex by using this 
>> construct:
>>
>> if !atomic.CompareAndSwapInt32(&s.myLock, 0, 1) {
>> fmt.Println("locked")
>> return
>> }
>> defer atomic.StoreInt32(&s.myLock, 0)
>> processData()
>>
>> Would this synchronise memory?
>>
>
> sync.atomic does synchronise memory, yes.
>

My understanding is that atomic does not 'synchronize memory' in general.  
If you use a Mutex, then *everything *that happened before is 
'synchronized'. If you use atomic then *only *the atomic variable is 
'synchronized'. That is kind of the point of using atomic. 

If I am wrong, please point me at the part of the Go Memory Model 
 that says otherwise. Personally, I have always 
felt that the go memory model, and specifically the guarantees of the 
atomic package are not as rigorously defined as I would like. But in this 
case, I'm pretty sure I am correct. 

-- 
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/0c51e772-cd1e-46ac-a34a-be84aa653cc9n%40googlegroups.com.

Re: [go-nuts] [generics] Constraint type inference not working

[jake...@gmail.com]

Submitted https://github.com/golang/go/issues/40859

On Tuesday, August 18, 2020 at 12:59:21 AM UTC-4 Ian Lance Taylor wrote:

> On Sun, Aug 16, 2020 at 7:42 AM jake...@gmail.com  
> wrote:
> >
> > When I try the example from the "Constraint type inference" section of 
> the Draft Design: 
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#constraint-type-inference
>  
> it does not seem to actually work:
> >
> > https://go2goplay.golang.org/p/pfq3QV6gdgf
> >
> > What am I missing?
>
> I'm not sure. Can you open a bug report? Thanks.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0c180e02-ac28-4c20-b42c-50ee51bdd7dbn%40googlegroups.com.

[go-nuts] Re: Mysterious RSS memory spike

[jake...@gmail.com]

If it helps any, I do not see this in Windows 10. After 5,000 iterations 
the "low memory" mark, as reported by windows, is still just 1,101MB. 

On Monday, August 24, 2020 at 5:05:00 AM UTC-4 vlad...@varank.in wrote:

> Hey,
>
> I haven't looked deep but I recall there had been a note about runtime 
> change in Go 1.13's https://golang.org/doc/go1.13#runtime That is
>
> > The runtime is now more aggressive at returning memory to the operating 
> system to make it available to co-tenant applications [..] However, on many 
> OSes, including Linux, the OS itself reclaims memory lazily, so process RSS 
> will not decrease until the system is under memory pressure. 
>
> Could that be the behaviour you observe (although, since you don't see the 
> same in C implementation, I might be confused, sorry in advance).
>
> On Sunday, August 23, 2020 at 5:05:22 PM UTC+2 Manish Rai Jain wrote:
>
>> Hey Gophers,
>>
>> I'm puzzled by a mysterious RSS memory spike in my Go program, when all 
>> memory allocations are happening via Cgo. I assert that there are no memory 
>> leaks in the program. And have written another C program with similar logic 
>> which does NOT show RSS memory spiking. So, I suspect this is something to 
>> do with Go memory.
>>
>> 
>> Program:
>>
>> https://github.com/dgraph-io/ristretto/pull/186
>>
>> This PR creates a Go memtest program, which does this:
>> - Uses z.Calloc and z.Free to allocate Go struct (S) and a byte slice 
>> inside it. All allocations are happening in Cgo, and being type casted into 
>> Go. No allocations are happening in Go (except a 32 MB fill slice).
>> - z.NumAllocBytes is tracking memory allocated and freed by these calls.
>> - Increases memory usage to 16 GB (as reported by z.NumAllocBytes).
>> - Decreases it back to 1 GB.
>> - Repeats this cycle.
>> - On Ctrl+C, it deallocates everything and asserts that Cgo memory 
>> allocated is zero.
>>
>> I was concerned about memory fragmentation, so created a very similar C 
>> program which does the same thing (memtestc).
>>
>> Please feel free to run either of the Go or C programs. They should 
>> compile and run easily.
>>
>> Behavior:
>>
>> Run the program with: `go build . && ./memtest` . Go pprof heap shows 32 
>> MB used, to account for the fill slice. However, RSS reported keeps roughly 
>> increasing every cycle.
>>
>> I'm using Go 1.14.4 and on it, RSS jumps to 22GB after a few cycles. 
>> memtestc 
>> (C equivalent, compiled with gcc) does not show this behavior. The RSS goes 
>> down to 1GB-ish every cycle.
>>
>> Any clues why the RSS is much higher than expected in Go and keeps 
>> climbing in Go?
>>
>> —
>> Manish
>> Founder, https://dgraph.io
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/10a3bfa0-5672-4471-b7f1-5c2836baa55an%40googlegroups.com.

Re: [go-nuts] Windows Write Call Error when Writing to Network mapped Folder.

[jake...@gmail.com]

On Wednesday, September 23, 2020 at 1:26:10 PM UTC-4 helhadad wrote:

> Thanks Ian, 
> The root cause of this issue is not the hard drive, it is something with 
> overlapped offset and high offset values, need to be set to 0 to have a 
> smooth APPEND to the file.
> I need to use /x/sys/windows package to call this function WriteFile(handle 
> Handle, buf []byte, done *uint32, overlapped *Overlapped) (err error).
> However, there is neither examples nor clarification on how to use or call 
> the function.
>

Less than Ideal, but you could look at how others use it: 
https://github.com/search?l=Go&q=%22windows.WriteFile%22&type=Code

-- 
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/8ccecc38-cd2b-4d6e-9c84-fcfe19e7adb1n%40googlegroups.com.

[go-nuts] Re: Proper way of mocking interfaces in unit tests - the golang way

[jake...@gmail.com]

On Saturday, October 3, 2020 at 6:00:10 AM UTC-4 krish...@gmail.com wrote:

> Hey, 
>
> Thanks for both the explanations. They really make sense to me.
>
> I referred to the following link and thought assertions are against go 
> best practices => https://golang.org/doc/faq#testing_framework. 
>
 
I find the link, https://golang.org/doc/faq#testing_framework, to be 
confusing as well. I'm not clear on how the hypothetical "assert" it refers 
to is different from testing.T.Fatal() 
.
 
 

-- 
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/c96d148e-6b73-40d0-9e3c-b8666b2e9d6dn%40googlegroups.com.

[go-nuts] Re: Proposal to add Index operator methods

[jake...@gmail.com]

I stopped reading at the " Show example code before and after the change " 
because many of the examples of "before the change" code seem to be invalid 
in go, and the others do not do what you seem to imply they do.  Am I 
misinterpreting this section in some way? 

On Sunday, October 4, 2020 at 1:19:47 AM UTC-4 rha...@gmail.com wrote:

>
> I have written a proposal to add index operator methods to Go2 here [1]. I 
> would love to hear your commends, thank you.
>
> [1] 
> https://medium.com/@rhadar/go2-proposal-index-operator-methods-edc621cfefca
>

-- 
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/d7c4fbcd-8c16-4d11-87c3-1291e83636d9n%40googlegroups.com.

Re: [go-nuts] Re: Proposal to add Index operator methods

[jake...@gmail.com]

The examples I was looking at are gone now. That section has been 
completely rewritten. So its kind of moot. Its possible that I was 
confusing the 'before' and 'after' examples, since they were not clearly 
labeled. In any case the rewritten version seems to make sense now. 

On Sunday, October 4, 2020 at 4:50:10 PM UTC-4 kortschak wrote:

> On Sun, 2020-10-04 at 09:06 -0700, jake...@gmail.com wrote:
> > I stopped reading at the " Show example code before and after the
> > change " because many of the examples of "before the change" code
> > seem to be invalid in go, and the others do not do what you seem to
> > imply they do. Am I misinterpreting this section in some way? 
> > 
>
> I'm curious as to which examples of "before the change" you think are
> invalid. From what I can see there, one is borderline (in the last
> example there is no package selector, but it could have been a dot
> import and is likely this way for brevity). The rest look like normal
> method invocations, which are the standard way for this kind of thing
> to be done in the current implementations of matrix and tensor
> operations in Go.
>
> Dan
>
>
>

-- 
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/903f4427-99d3-4ed3-83e9-1fd363dae413n%40googlegroups.com.

Re: [go-nuts] Trying to call powershell script from Go

[jake...@gmail.com]

It might help if you posted an actual runnable program, that you have 
personally run, and the full output. 

On Tuesday, October 27, 2020 at 1:26:53 PM UTC-4 mua...@gmail.com wrote:

> Hi Marvin,
>
> If I add script.ps1 in double quotes and try to run, it tells me cmdName 
> declared but no used.
> Yes, the script is named script.ps1. The script is not a variable.
>
> On Tuesday, October 27, 2020 at 8:22:14 PM UTC+3 Marvin Renich wrote:
>
>> * Uzair Ally  [201027 12:25]:
>> > Hi,
>> > 
>> > I am getting the following error when I try to call a powershell script 
>> > from go.
>> > 
>> > undefined: script
>> > 
>> > Here is the code:
>> > 
>> > cmdName := 
>> "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
>> > out, err := exec.Command("cmdName", script.ps1).Output()
>>
>> Perhaps you what you intended was:
>> out, err := exec.Command("cmdName", "script.ps1").Output()
>>
>> Is your script named script.ps1 or is script a variable with a field
>> named ps1 containing the name of the script?
>>
>> > if err != nil {
>> > fmt.Fprintln(os.Stderr, "Error creating StdoutPipe for Cmd", err)
>> > 
>> > 
>> > It looks like go doesn't recognize the powershell script. How do I 
>> resolve 
>> > this error? Any help or guidance will be appreciated. 
>>
>> ...Marvin
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/40b346d7-11f1-460a-bc0a-e7063ffb1f3bn%40googlegroups.com.

Re: [go-nuts] Trying to call powershell script from Go

[jake...@gmail.com]

Technically your code is not runnable, since it does not compile. I 
misunderstood, and thought you were having a problem with running a 
powershell script from Go, but actually you are having a problem compiling 
the code. Very different problems. So never-mind ;-)
On Tuesday, October 27, 2020 at 2:18:25 PM UTC-4 mua...@gmail.com wrote:

> Hi Jake,
>
> The code I posted is the runnable go program just missing the powershell 
> script which is a separate file. Maybe I'm miss understanding? Is there 
> something else I can provide to help you understand further?
>
> On Tuesday, October 27, 2020 at 8:48:54 PM UTC+3 jake...@gmail.com wrote:
>
>> It might help if you posted an actual runnable program, that you have 
>> personally run, and the full output. 
>>
>> On Tuesday, October 27, 2020 at 1:26:53 PM UTC-4 mua...@gmail.com wrote:
>>
>>> Hi Marvin,
>>>
>>> If I add script.ps1 in double quotes and try to run, it tells me cmdName 
>>> declared but no used.
>>> Yes, the script is named script.ps1. The script is not a variable.
>>>
>>> On Tuesday, October 27, 2020 at 8:22:14 PM UTC+3 Marvin Renich wrote:
>>>
>>>> * Uzair Ally  [201027 12:25]: 
>>>> > Hi, 
>>>> > 
>>>> > I am getting the following error when I try to call a powershell 
>>>> script 
>>>> > from go. 
>>>> > 
>>>> > undefined: script 
>>>> > 
>>>> > Here is the code: 
>>>> > 
>>>> > cmdName := 
>>>> "C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe" 
>>>> > out, err := exec.Command("cmdName", script.ps1).Output() 
>>>>
>>>> Perhaps you what you intended was: 
>>>> out, err := exec.Command("cmdName", "script.ps1").Output() 
>>>>
>>>> Is your script named script.ps1 or is script a variable with a field 
>>>> named ps1 containing the name of the script? 
>>>>
>>>> > if err != nil { 
>>>> > fmt.Fprintln(os.Stderr, "Error creating StdoutPipe for Cmd", err) 
>>>> > 
>>>> > 
>>>> > It looks like go doesn't recognize the powershell script. How do I 
>>>> resolve 
>>>> > this error? Any help or guidance will be appreciated. 
>>>>
>>>> ...Marvin 
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b7ff6be7-7578-42d0-86b5-628682be9531n%40googlegroups.com.

[go-nuts] Re: use same for/range code on a hash map but it has different result

[jake...@gmail.com]

I'm not sure what strange way you decided to show your code, but in my 
Firefox browser all I see is two empty boxes. Please use fixed width *plain 
text* for all code in this group. Thanks. 

On Tuesday, November 10, 2020 at 9:12:54 AM UTC-5 Kilos wrote:

> when I run the same code like this 
> https://play.golang.org/p/fSPpo4_-k57,most of the time it print A,B,C and 
> D,but sometimes it just print A,B and C,why ???
>

-- 
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/121c636a-ed61-482f-a404-01635160c708n%40googlegroups.com.

Re: [go-nuts] detecting cyclic references

[jake...@gmail.com]

FYI, that does detect the simple case of l[0] = l, but not more complicated 
circular cases like l[1] = l[1:]

On Tuesday, November 10, 2020 at 2:38:26 AM UTC-5 axel.wa...@googlemail.com 
wrote:

> If the slice is empty, it doesn't reference anything.
> If it is not empty, &x[0] can be used to identify the slice (potentially 
> also using len/cap, if it's interesting).
>
> On Tue, Nov 10, 2020 at 4:11 AM arpad ryszka  wrote:
>
>> Hi,
>>
>> is there a way to detect the cyclic reference in the following example 
>> somehow? Either via reflection or by other means? My understanding is that 
>> slices cannot be compared with == (unless to nil), or used as keys in maps. 
>> Is there a different way?
>>
>> l := []interface{}{"foo"}
>> l[0] = l
>> fmt.Println(l)
>>
>> or here it is as a playground link: https://play.golang.org/p/T0qZlF8m-vi
>>
>> Cheers,
>> Arpad
>>
>> -- 
>> 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/b2cb6b5e-febc-407f-b5b3-d9ca196ce68bn%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/250107e9-f688-4205-ae52-728221eb2e4cn%40googlegroups.com.

Re: [go-nuts] Re: Local variable escapes to heap

[jake...@gmail.com]

For me, the example you gave of sorty is a strong argument against adding 
go:local. If I understand correctly, using go:local, if a variable marked 
this way actually does escape it would cause undefined behavior, possibly 
in unrelated code. This is the type of bug that is very, very hard to find 
and fix. Using your example of  ./sortyI8.go:319:2 
,
 
if I were doing a code review, or reading the code later, it would take a 
minute to realize that the intent was for sv, and especially sv.done not to 
live past the end of the function. But then, as a reviewer, I would want to 
make sure that was actually the case. Turns out sv, and its members are 
used in a tangled web of function calls and goroutines, some of which are 
multiple layers deep. I gave up trying to track all of it after about 12 
code jumps in my browser. One of the benefits of go, and the "go style" is 
that it should be easy to read and understand. 

I'm not saying that there is no benefit to adding something like go:local, 
just that the bar would be very, very high in my opinion.  

On Saturday, November 21, 2020 at 10:26:16 AM UTC-5 jfcg...@gmail.com wrote:

> In sorty  (commit e4fb296daf1d90037d) I 
> see:
>
> $ go build -gcflags -m |& grep -i heap
> ./sortyI8.go:319:2: moved to heap: sv
> ./sortyU8.go:319:2: moved to heap: sv
> ./sortyF4.go:319:2: moved to heap: sv
> ./sortyF8.go:319:2: moved to heap: sv
> ./sortyI4.go:319:2: moved to heap: sv
> ./sortyLsw.go:338:2: moved to heap: sv
> ./sortyS.go:319:2: moved to heap: sv
> ./sortyU4.go:319:2: moved to heap: sv
>
> Local variable sv for synchronization (that I know would be safe to stay 
> local like the simplified example) escapes to heap. It is the one and only 
> thing that escapes to heap and I want to get rid of it with something like 
> *go:local* :)
> On Saturday, November 21, 2020 at 5:10:46 PM UTC+3 Ian Lance Taylor wrote:
>
>> On Sat, Nov 21, 2020 at 12:11 AM jfcg...@gmail.com  
>> wrote: 
>> > 
>> > I have the following: 
>> > 
>> > package myf 
>> > 
>> > func F1(x *int, ch chan bool) { 
>> > *x += 1 
>> > ch <- false 
>> > } 
>> > 
>> > func F2() { 
>> > var x int 
>> > ch := make(chan bool) // or with buffer 
>> > go F1(&x, ch) 
>> > <-ch 
>> > } 
>> > 
>> > I get this when I build with go 1.15.5 via go build -gcflags '-m -m' : 
>> > 
>> > 3:6: can inline F1 with cost 7 as: func(*int, chan bool) { *x += 1; ch 
>> <- false } 
>> > 8:6: cannot inline F2: unhandled op GO 
>> > 3:9: x does not escape 
>> > 3:17: ch does not escape 
>> > 9:6: x escapes to heap: 
>> > 9:6: flow: {heap} = &x: 
>> > 9:6: from &x (address-of) at ./heap.go:11:8 
>> > 9:6: from F1(&x, ch) (call parameter) at ./heap.go:11:7 
>> > 9:6: moved to heap: x 
>> > 
>> > So x is allocated on the heap and needs gc when F2() returns. I know 
>> F2() will wait for F1() and passing &x is safe if it was local. So how can 
>> I tell this to go compiler and avoid allocation/gc costs? Do we need a new 
>> go:local directive to mark such variables? 
>>
>>
>> It would help to have a more realistic example. I don't yet see any 
>> reason why people would write code like this, so it doesn't seem worth 
>> optimizing. 
>>
>> If something like this is worth optimizing, the first thing to look 
>> into would be whether the compiler's escape analysis can improve to 
>> handle that case. A go:local directive seems very easy to misuse, and 
>> doesn't seem like a good fit for the Go language. 
>>
>> Ian 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/00ded9c0-90fb-48f4-864f-3183cedde07cn%40googlegroups.com.

[go-nuts] Re: Garbage Collector triggering when deleting an object

[jake...@gmail.com]

On Monday, November 23, 2020 at 6:31:50 AM UTC-5 tokers wrote:

> Are there any documents?
>
 
https://golang.org/pkg/runtime/#SetFinalizer 

-- 
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/7ad09162-8033-46b4-ae02-74cd11889f77n%40googlegroups.com.

[go-nuts] Re: iterate over Interface

[jake...@gmail.com]

I'm genuinely confused about what you are trying to accomplish. In the code 
you posted you don't iterate over anything. Also, the variables d and f in 
your code are completely redundant. You could remove the 4 lines and simply 
` fmt.Println("Output", pslice )`, and get the same result. So, perhaps you 
could be more precise about what you have and what you want to do with it. 
For example, do you have an interface{} that you *know *contains a 
[]product, and want to actually iterate over all the product items? or 
something else?

On Friday, December 11, 2020 at 10:20:21 AM UTC-5 Salim Aft wrote:

> Could someone help,
>  I am trying to itreate over  an interface and fetch the "id" and "name" 
> in below code,
> is there a better way to do this.
>
> package main
>
> import (
> "fmt"
> )
>
>  type product struct {
>  id int
>  name string
>  }
> func main(){
> fmt.Println("Hello ALLTEST")
> p := product{id : 12, name:"apple"}
> c := product{id : 13, name:"samsung"}
> var pslice []product
> pslice = append(pslice, p)
> pslice = append(pslice, c)
> d := map[string]interface{}{
> "allproducts" : pslice,
> }
> f:= d["allproducts"]
> fmt.Println("Output", f)
>

-- 
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/32af3985-0099-41fe-bbc9-810c86e9cfd3n%40googlegroups.com.

[go-nuts] Re: Good books to learn Golang deeply?

[jake...@gmail.com]

Two previous posts on this topic:
https://groups.google.com/g/golang-nuts/c/chxehZ29uOQ/m/0DeZBJiMCAAJ
https://groups.google.com/g/golang-nuts/c/hU_cLsp1r70/m/NvIcU-KcCAAJ

You might also find some interesting ideas in:
https://groups.google.com/g/golang-nuts/search?q=subject%3Alearn

On Monday, December 14, 2020 at 12:45:50 PM UTC-5 Facundo Yuffrida wrote:

> I'm looking for recommended books to learn Golang deeply and also some 
> writer to follow his books and his line of thinking.

-- 
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/6a35942b-ce2b-43e1-abeb-ae5d7131f48bn%40googlegroups.com.

[go-nuts] Re: Purpose of pattern in muxEntry

[jake...@gmail.com]

I have no special knowledge of the code, but it looks like the reason is so 
that ServeMux.es,  which is a []muxEntry, can be searched. See the latter 
half of `func (mux *ServeMux) match() 
` for example. 

That said, it may be possible to have ServeMux.m be a `map[string]Handler` 
instead. If so, then my guess is that ServeMux.m and ServeMux.es both use 
muxEntry just to slightly simplify the code. The assumption would be that 
the memory cost is negligible. But I could be wrong, and maybe there is a 
case where  ServeMux.m must be a muxEntry, and not just a Handler. 

On Monday, December 14, 2020 at 8:52:27 PM UTC-5 amits...@gmail.com wrote:

> Hi all, the ServerMux struct is currently defined as:
>
> type ServeMux struct {
> // other fields
> m map[string]muxEntry
> }
>
>
> The muxEntry is then defined as:
>
> type muxEntry struct { 
> h Handler 
> pattern string 
> }
>
> Is there any reason for also storing the pattern in the muxEntry since it 
> *seems* like the lookup only happens using the key in the map of ServeMux?
>
> Thanks for any insights.
>
>
> Best Regards,
> Amit
>
>
>

-- 
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/42544681-9f1f-4e76-a4da-52330ee1628en%40googlegroups.com.

[go-nuts] Re: How to set the "godebug" environment variable from the go file?

[jake...@gmail.com]

Could you explain in more detail why you want to always run with 
cgocheck=0. That seems ill advised at first glance. I'm not sure what that 
has to do with "I want to disable some controls."

On Wednesday, December 16, 2020 at 11:50:04 AM UTC-5 Sean wrote:

> hi all,
> i have a project I have to work with CGo. I want to disable some 
> controls as they are not good enough right now.
> It works when I write "set godebug=cgocheck=0" on Windows in console.
> However, this is a GUI program. Console should not open.
>
> I tried this with "os.Setenv". I define it in "func init" it doesn't work.
>
> Something like this:
>
> func init() {
> os.Setenv("godebug", "cgocheck=0")
> }
>
> What should I do?
>
>

-- 
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/ecedb572-3a3a-4f4f-9b0f-703722922c87n%40googlegroups.com.

[go-nuts] Re: The GitHub Vet Project

[jake...@gmail.com]

On Tuesday, December 29, 2020 at 1:21:04 PM UTC-5 k.alex...@gmail.com wrote:

> I'd like to solicit some input from the community regarding a decision 
> that could reduce the effort required in crowdsourcing.
>
> After thinking carefully about the loopclosure vet check 
> ,
>  
> it seems to me that any time it reports an issue, there actually is an 
> issue. That has also been the case for everything I've seen GitHub Vet 
> report from loopclosure thus far.
>
> What loopclosure does is find instances where a range loop variable is 
> used inside a goroutine or defer statement. My understanding is that, in 
> every case, this raises the potential for a race-condition between updating 
> the range loop variable and reading from it within the body of the 
> goroutine. So unless I'm missing something, it seems to me that there is 
> not any need for a human to double-check loopclosure results.
>

Technically, I believe a range loop variable can be used in a goroutine 
safely. A very contrived example: https://play.golang.org/p/jgZbGg_XP6S . 
In practice I can not see much use for this kind of pattern, but it does 
exist. 
 

>
> So my plan -- unless someone comes up with something I have missed -- is 
> to omit loopclosure findings from the crowdsourcing effort. Once this 
> change is made, loopclosure findings will be kept on disk, but not uploaded 
> to GitHub for crowdsourcing.
>
> It's worth mentioning that there are issues which loopclosure misses which 
> VetBot is able to find, and the community's effort will still be needed to 
> help sift through false-positives once the project has stabilized.
>
>
> On Sun, Dec 20, 2020 at 12:08 PM K. Alex Mills  
> wrote:
>
>> Hello Gophers!
>>
>> During a Q&A session at this year's GopherCon, some members of the Go 
>> language team indicated a willingness to modify the behavior of range 
>> loops  *if* we can be 
>> reasonably certain that the change will not cause incorrect behavior in 
>> current programs. To make that determination, a large collection of 
>> real-world go programs would need to be vetted. If we can find that, in 
>> every case, modifying the compiler behavior does not lead to an undesirable 
>> outcome, we will have strong evidence that the change may only have a small 
>> impact.
>>
>> I've been working on a project to gather and crowdsource data for that 
>> sort of analysis. It has reached a point where I think that it's time to 
>> share it with the Go community.
>>
>> The GitHub Vet Project  performs static 
>> analysis on public Go repositories hosted on GitHub in order to better 
>> understand the impact of this proposed language change 
>> . It consists of two bots. 
>> VetBot crawls GitHub to snippets of code it thinks could be interesting, it 
>> reports it as an issue in a separate repository 
>> , for humans 
>> to analyze via crowdsourcing. TrackBot 
>>  manages the 
>> crowdsourcing workflow.
>>
>> At this point, all of the features I think are necessary for the 
>> project's success have been implemented. But I am only one Gopher, and so I 
>> would like to a) make the community aware of the project and b) ask the 
>> community to help review it in three ways:
>>
>> 1) Test out TrackBot and the project instructions by actually 
>> crowdsourcing through the issues found so far 
>> .
>> 2) Review the output 
>>  and 
>> raise concern if anything that I claim ought to be excluded 
>> 
>>  
>> is somehow making it through.
>> 3) Static analysis experts: review the analyzers 
>>  and 
>> ruthlessly question anything that could lead to a false negative. I don't 
>> think anything exists, but one pair of eyes is often wrong, and there are 
>> many folks on this list with (much) more expertise than me.
>>
>> One final thing. The crowd-sourcing workflow I've designed relies on the 
>> opinion of experts to help estimate the reliability of the community 
>> assessment. In order for that to work, I need the help of some Go experts 
>> who are willing to commit some time to reviewing the findings. If you'd 
>> like to participate in this way, first, read the TrackBot documentation 
>>  to 
>> understand what being an expert entails. If you're still interested, email 
>> me with the subject line 'GitHub Vet Expert' and include your GitHub 
>> username and a brief outline of your experience with Go.
>>
>> 

[go-nuts] Re: Waitgroup problem

[jake...@gmail.com]

There may be other problems as well, but the WaitGroup.Add 
 documentation says:
" If a WaitGroup is reused to wait for several independent sets of events, 
new Add calls must happen after all previous Wait calls have *returned*." 

You have a race condition. What I believe is happening is the following:

   - The last goroutine calls `Barrier(w, "start", wgstart)`. That calls 
   barrier.Done(). It then calls Wait(), but Wait() has not returned. 
   - Meanwhile main() calls `Barrier(threads, "start", &wgstart)`. The 
   Wait() in that call returns because all the goroutines have called Done(). 
   - main() calls `wgstart.Add(threads + 1)`
   - The goroutine from above is still in the Wait() call, hence the 
   panic.  

There is also another possible scenario, that is not causing the panic I 
see, but could cause incorrect behavior:

   - The last goroutine calls `Barrier(w, "start", wgstart)`. That calls 
   barrier.Done(). 
   - Meanwhile main() calls `Barrier(threads, "start", &wgstart)`. The 
   Wait() in that call returns because all the goroutines have called Done(). 
   - main() calls `wgstart.Add(threads + 1)`
   - The goroutine from above now calls Wait(), but since Add was already 
   called, it blocks. That goroutine is now 'stuck',  because Wait() will 
   never return, which will in turn end up blocking all the other goroutines 
   eventually. 
   
Honestly, I think you need to rethink your whole model.

Hope that helps. 
On Saturday, January 16, 2021 at 11:28:59 AM UTC-5 Pete Wilson wrote:

> Gentlepersons
>
> I asked for advice on how to handle a problem a few days ago, and have 
> constructed a testbed of what I need to do, using WaitGroups in what seems 
> to be a standard manner.
>
> But the code fails and I don’t understand why.
>
> The (simple version of) the code is at 
> https://play.golang.org/p/-TEZqik6ZPB
>
> In short, what I want to do is to have a controller goroutine (main) plus 
> some number of worker goroutines
>
> I implement a Barrier function which operates on a properly-initialised 
> waitgroup.
>
> The Barrier function simply does Done() then Wait()
>
> What I want is that each worker does a two-phase operation
> - wait until everybody has passed a start barrier
> - do some work
> - wait until everybody has passed an end barrier
> - do some work
>
> .. doing this some number of times
>
> In parallel, main has created and initialised the start and end waitgroups 
> wgstart and wgend
> main has then created the worker goroutines (in the real thing I want 
> roughly one worker per core, so there’s also some setting of GOMAXPROCS)
> main then enters a loop in which it
>
> - waits until everbody including it has passed the start barrier
> - resets the start barrier
> - waits until everybody has bassed the end barrier
> - resets the end barrier
>
> This behaviour is observed, except the code panics, both in the playgorund 
> and on my machine. Typical failure is:
>
> --- [2] main about to barrier start ---
>
>   w[7] enters barrier startpanic: sync: WaitGroup is reused before 
> previous Wait has returned
>
> goroutine 10 [running]:
> sync.(*WaitGroup).Wait(0xc2c030)
>   /usr/local/go-faketime/src/sync/waitgroup.go:132 +0xae
> main.Barrier(0x4, 0x4bef21, 0x3, 0xc2c030)
>   /tmp/sandbox686473236/prog.go:51 +0x12b
> main.worker(0x4, 0xc2c020, 0xc2c030, 0xa)
>   /tmp/sandbox686473236/prog.go:35 +0x309
> created by main.main
>   /tmp/sandbox686473236/prog.go:78 +0x295
>
>
> What have I misunderstood and done wrongly?
>
> Thanks!
>
> — P
>
>
>
>
> *WARNING / LEGAL TEXT: This message is intended only for the use of the 
> individual or entity to which it is addressed and may contain 
> information which is privileged, confidential, proprietary, or exempt from 
> disclosure under applicable law. If you are not the intended recipient or 
> the person responsible for delivering the message to the intended 
> recipient, you are strictly prohibited from disclosing, distributing, 
> copying, or in any way using this message. If you have received this 
> communication in error, please notify the sender and destroy and delete any 
> copies you may have received. http://www.bsc.es/disclaimer 
>  *
>
>
>
>
>
>
> WARNING / LEGAL TEXT: This message is intended only for the use of the 
> individual or entity to which it is addressed and may contain information 
> which is privileged, confidential, proprietary, or exempt from disclosure 
> under applicable law. If you are not the intended recipient or the person 
> responsible for delivering the message to the intended recipient, you are 
> strictly prohibited from disclosing, distributing, copying, or in any way 
> using this message. If you have received this communication in error, 
> please notify the sender and destroy and delete any copies you may have 
> received. 
>
> http://www.bsc.es/disclaimer 
>

-- 
You r

[go-nuts] Re: Quick question about the generics alternatives that have been considered

[jake...@gmail.com]

If I understand correctly, this question is specifically addressed by the 
design draft: 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#why-not-put-type-parameters-on-packages

On Wednesday, January 20, 2021 at 10:22:19 AM UTC-5 atd...@gmail.com wrote:

> Hello,
>
> It' has probably been discussed somewhere but I am curious about what 
> might have been the issues when considering an implementation of generics 
> that would parameterized packages?
>
> The rationale being that usually, packages have a non-mutable interface 
> for the user and are the ompilation unit if I'm not mistaken. So why not 
> just relax the interface exposed by a package and allow for package-wide 
> type specialization?
>
> In terms of pure parametric polymorphism, having packages with a mutable 
> interface in terms of types (via mutation of type aliases for instance) 
> would just be the next iteration. It may require a little bit more from the 
> build tool but the type checking would not have to change I think. The 
> constraints on the parameter would stem implicitly from the code within a 
> package in terms of operations used and interfaces being implemented.
>
> I would expect such "parameterized" packages to be rare, non-pervasive if 
> not for the simple fact that most parameterized package would mostly be 
> able to import other generic packages since they would be defined with 
> abstract types. The compiler may still want to insure that the constraints 
> make sense throughout the dependency tree  of generic imports incrementally 
> but I don't think that that would be a huge problem.
>
> I think that it could be something orthogonal to the design of type 
> constraintd, notably type Lists, that are anyway highly desirable imo but 
> more so to constrain interfaces to a finite set of types ( as a way to have 
> union types, enums, sumtypes or whatnot).
>
>
>
>

-- 
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/d82f7ae9-40e2-484f-ae41-fcd597f47a0dn%40googlegroups.com.

[go-nuts] Re: Options other than pointers, regarding code duplication

[jake...@gmail.com]

Perhaps providing some code could be helpful. That way we can better 
understand what the issues are.  Minimally the function signatures you have 
now, and the signature of common function you are calling inside them, as 
well as the definitions of any types being passes. Of course, the full code 
of before and after would be ideal, if you can share. 

On Thursday, January 28, 2021 at 8:21:30 AM UTC-5 m8il...@gmail.com wrote:

> I have three logging functions that are almost identical.
>
> If I move the identicle code into a function without pointers then there 
> is a
> noticeable speed decrease. I know this is premature optimisation as logging
> shouldn't happen frequently enough or be that large (hopefully).
>
> That said. I am left wondering aside from code generation steps and copy 
> and
> paste (current solution) if I am unaware of any options that might avoid 
> pointer
> use, such as:
>
> 1./ scoped global, like a Class might provide
>
> 2./ macro type instantiation that simply inserts the code at compile time 
> but
> without the compiler doing any computations
>
> I assume not, from perusing the spec?
>
> p.s. It's fine if the solution is pointers. Just wondering if I can avoid 
> panic
> potential.
>

-- 
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/1a15ed31-29d2-4214-926a-b53d30abb27fn%40googlegroups.com.

[go-nuts] Re: normal mode and starve mode of sync.Mutex and runtime mutex?

[jake...@gmail.com]

What makes you think it does not? Have you looked at Mutex.lockSlow()? I 
have not really worked through the algorithm, but the comments do mention 
starvation mode.

On Sunday, January 31, 2021 at 10:15:23 AM UTC-5 cuiw...@gmail.com wrote:

> why mutex in runtime do not need starve mode?

-- 
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/76c0791f-0f44-494a-ae6e-7115e03b1acfn%40googlegroups.com.

[go-nuts] Re: how can I solve it 2 decimal places float32 with fmt.Println()

[jake...@gmail.com]

Can you tell us what the problem is that you want to solve? The code3 seems 
to run just fine.

On Thursday, March 4, 2021 at 11:31:57 AM UTC-5 Tareq Ibna wrote:

> package main 
> import "fmt"
>
> func main(){
>
>  //I want to solve this peoblen with fmt.Println()  please help.
>  
>
> var a, b ,c float32
>
> fmt.Println(" Enter 1st number:" )
> fmt.Scan( &a)
>
> fmt.Println(" Enter 2nd number:" )
> fmt.Scan( &b)
> c= a/b 
>
>fmt.Printf(" %.2f", c) 
>
>
>
>
> }
>

-- 
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/ad1cd4cc-9715-4319-a29e-66c8c32c9c9an%40googlegroups.com.

[go-nuts] Re: Windows Event logs

[jake...@gmail.com]

I can't help directly, but since no one else has responded, maybe this will 
help. 

The windows API call OpenEventLogW() would be the first step. Looking on 
Github for examples of Go code that makes this call (
https://github.com/search?p=2&q=OpenEventLogW+language%3AGo&type=Code), you 
may be able to see how other folks have done it. The package that comes up 
the most is winlogbeat/sys/eventlogging 
.
 
I'm not sure if this is the actual main repo, because there are so many 
forks. The Readme.md  
does not seem to indicate what the original repo is. 

Anyway, you may be able to use that package directly, or mine it for 
examples. 

Hope this helps.

On Tuesday, March 9, 2021 at 12:21:46 PM UTC-5 karanmm...@gmail.com wrote:

> Hello,
>can anyone help please help me with fetching windows Event logs in 
> golang or maybe 
> you can refer something. 
>
> It would really help full
>
> Thanks 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5966de27-2967-49da-ba21-b01a68607c11n%40googlegroups.com.

Re: [go-nuts] What does `go install path/to/main.go` do with GO111MODULE=on?

[jake...@gmail.com]

What version of Go are you using?

On Wednesday, March 10, 2021 at 6:20:50 PM UTC-5 mattm...@gmail.com wrote:

> Thanks for the message! Unfortunately, 
>
> GOBIN=$GOPATH/bin go install ./cmd/app/main.go
>
> Doesn't change anything. Actually I'm realizing that even without go 
> modules but with $GOPATH this never installed anywhere:
>
> GOBIN=$GOPATH/bin GO111MODULE=off go install ./cmd/testinstall/main.go
>
> You have to do:
>
> cd ./cmd/app && go install
>
> Then it appears to work in all cases. 
>
> I'm assuming this is by design, but it feels to me like go install 
> ./cmd/app/main.go silently failing is a bug.
>
> Is this worth opening an issue for?
>
>
> On Thursday, March 11, 2021 at 12:08:09 AM UTC+1 Kurtis Rader wrote:
>
>> Do you have environment var GOBIN set? Check the output of "go env 
>> GOBIN". See https://golang.org/ref/mod#mod-commands.
>>
>> On Wed, Mar 10, 2021 at 2:59 PM Matt Mueller  wrote:
>>
>>> Hey folks, 
>>>
>>> I'm trying to install a command inside a module globally on my system so 
>>> that I can use that binary elsewhere. During the $GOPATH era this worked 
>>> something like this:
>>>
>>> go install cmd/app/main.go
>>> // installed app to $GOPATH/bin
>>>
>>> Unfortunately that doesn't seem to work anymore. It doesn't error, but I 
>>> don't know where it installed the binary. Not in $GOPATH/bin.
>>>
>>> I've read the documentation for `go help install`. It pointed me to `go 
>>> help modules`, but then I got lost after that.
>>>
>>> Any pointers would be greatly appreciated. Thanks!
>>>
>>> Matt
>>>
>>> -- 
>>> 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/ad5e444b-7d40-464b-9848-e2135d1788e0n%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>
>>
>> -- 
>> Kurtis Rader
>> Caretaker of the exceptional canines Junior and Hank
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e3c9-41ce-4a39-864f-8a39070f7218n%40googlegroups.com.

[go-nuts] Re: No generic, part -2

[jake...@gmail.com]

This thread seems like it has devolved into a rehashing of the recent Generics, 
please go away! thread 
. 
This seems unfair to the original poster, who asked a simple , respectful, 
question in good faith, and seems to be satisfied with the answers he got. 
This tread is now so devolved that it would be hard for him to even ask a 
followup. I would respectfully suggest that those wanting to rehash the 
generic debate please continue on the  Generics, please go away! thread 
. 

[I will no longer be following this thread]

- Jake

On Friday, March 12, 2021 at 10:30:49 AM UTC-5 alex-coder wrote:

> Hello again, 
> I apologize for being so intrusive. 
> Where it is possible to read about the evaluations of labor and complexity 
> for 
> GO itself for different implementations to introduce generic in GO ?
>
> Thank you.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/678e9dc6-7c68-4048-9708-6b137e0ce7cdn%40googlegroups.com.

[go-nuts] How to search standard libarary?

[jake...@gmail.com]

For years now, when I needed to casually lookup a standard library function 
I would use the search on the website. Like 
https://golang.org/search?q=Rename. This no longer works, and the search 
box on the Go website and "Package Documentation" page is now gone. 

Has this moved somewhere else? How do I do a quick web-browser based search 
of the standard libraries? 

I know I can use 'go doc', but that is not web based, and AFAICT, only 
works if you know the exact package the function is in.

Any suggestions?

-- 
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/599eba82-5447-44d7-b151-2e513065ede6n%40googlegroups.com.

[go-nuts] Re: How to search standard libarary?

[jake...@gmail.com]

On Tuesday, March 16, 2021 at 11:28:06 AM UTC-4 Carla Pfaff wrote:

> On Tuesday, 16 March 2021 at 15:09:25 UTC+1 jake...@gmail.com wrote:
>
>> Any suggestions?
>
>
> You can use this: https://cs.opensource.google/go 
>

While that may be useful in its own way, it is not useful for what UI asked 
for. It searches the  library *sources*, not the *documentation*.

-- 
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/5bf24f31-37b5-40b1-b024-503763640d59n%40googlegroups.com.

Re: [go-nuts] How to search standard libarary?

[jake...@gmail.com]

On Tuesday, March 16, 2021 at 11:31:51 AM UTC-4 eli...@gmail.com wrote:

> I really like devdocs.io for this
>
> You type "Go" and TAB, and then it will only autocomplete in the Go stdlib.
>

Thanks, that seems to do what I want. 

It seems like a real oversight that there is no search on the official go 
documentation though. It seems like it would be really helpful, especially 
to beginners. I would love to hear from someone involved why the go team 
decided to remove this feature from the official Go website. 

-- 
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/061f6160-10af-4587-9d92-30388b3869e9n%40googlegroups.com.

Re: [go-nuts] Searching recursively in GOLANG

[jake...@gmail.com]

You could also achieve this using the regexp package. But, in this case, it 
would probably be overkill. 

On Tuesday, March 16, 2021 at 2:55:29 AM UTC-4 Sharan Guhan wrote:

> Thanks for the tip!  I just wanted to make sure, I am not missing some 
> basic API out there.. Will code this up :-)
>
> Sharan
>
> On Mon, Mar 15, 2021 at 11:18 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Tue, Mar 16, 2021 at 7:06 AM Sharan Guhan  wrote:
>>
>> > Seems a trivial problem, but unable to find the right imports to do 
>> this.. Want to search for a substring in a huge string ( output of a 
>> exec.command) and get the index for every occurrence of that substring.  I 
>> used Index and LastIndex, both give first and last, but am looking for 
>> IndexNext kind of till the last occurrence
>> >
>> > For example : "Hello this is Golang program Golang has a variety of 
>> import utilities.I like to code in Golang"
>> >
>> > In the above example, I want an API which will return each occurrence 
>> of Golang
>>
>> The API is your keyboard ;-) Joking aside, it's easy to write a loop
>> that uses Index to find out the first position, slice the string to
>> remove the occurrence and find another until no more exists.
>>
>

-- 
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/bed45b45-94e8-40f4-9049-22d919ff1803n%40googlegroups.com.

Re: [go-nuts] How to search standard libarary?

[jake...@gmail.com]

On Tuesday, March 16, 2021 at 11:59:31 AM UTC-4 Jan Mercl wrote:

> Entering `rename site:golang.org/pkg`  in Chrome 
> seems to work well, for example. 
>
> (But I'm not using this kind of search so there might be some issues 
> I'm not aware of.) 
>
> I'm unclear what you are suggesting. How does this search? 

-- 
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/3dcfcce9-eced-4804-a8ac-4fee594d2e79n%40googlegroups.com.

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

[jake...@gmail.com]

 > 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/7d5a3005-738f-4ac6-8155-b8a446193374n%40googlegroups.com.

[go-nuts] Re: Where is the display profile from x/net/idna defined

[jake...@gmail.com]

I'm guessing you want to know where the behavior is documented? That I do 
not know. 

But in case you literally want to know where it is defied, look at : 
https://github.com/golang/net/blob/0fccb6fa2b5ce302a9da5afc2513d351bd175889/idna/idna10.0.0.go#L265

On Sunday, April 4, 2021 at 9:03:10 AM UTC-4 s...@samwhited.com wrote:

> Hi all,
>
> Does anyone know where the Display profile from x/net/idna [1] is
> defined?
>
> I thought it corresponded to the rules defined in RFC 5895 [2], but it
> also appears to apply the Bidi rule and some other things not defined
> there. Unlike the other profiles the Display one has no comment saying
> where it's defined.
>
> Thanks for the help.
>
> —Sam
>
> [1]: https://pkg.go.dev/golang.org/x/net/idna#Display
> [2]:https://tools.ietf.org/html/rfc5895
>
> -- 
> Sam Whited
>

-- 
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/2c4dd165-8dd9-42bf-bfd5-fa2349492ae1n%40googlegroups.com.

Re: [go-nuts] Syscalls that take structs with embedded pointers

[jake...@gmail.com]

On Friday, May 14, 2021 at 10:28:24 AM UTC-4 Michael Pratt wrote:

> Go has a non-moving GC [1], so that is not an issue. 
>
 
It is my understanding that the go team has always explicitly maintained 
the 'right' to change the GC to allow moving memory. Or to allow another 
implementation of the Go language to do so. That is the purpose of some of 
these rules. So if you write code that assumes a non-moving GC, then be 
prepared for breakage later. 

I know that the standard libraries do things that violate those rules, 
because they are tied to the Go version they ship with. So the Go team will 
adjust them as necessary when changes are made to Go. I am not entirely 
clear if this logic applies to the  golang.org/x libraries 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/2df2d684-0c12-4697-ab9e-568bf97870c1n%40googlegroups.com.

[go-nuts] Re: embedding files in tests

[jake...@gmail.com]

I would strongly assume that the file is only embedded in the test binary. 
In fact it is hard to imagine a design where it would not be that way. 
If you really want to make sure, you could easily build two, identical 
binaries, that differ only in that a very large file is embedded in the 
test file for one, and compare sizes. 
On Tuesday, June 1, 2021 at 9:17:11 AM UTC-4 manlio@gmail.com wrote:

> When a file is embedded in a test file, will the file be embedded only in 
> the test binary?
> The documentation says nothing about this case, but the data from go list 
> seems to confirm that the file is only embedded in the test binary.
>
> Thanks
> Manlio
>

-- 
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/f9f0df28-3319-43ee-a34a-d638a6008767n%40googlegroups.com.

Re: [go-nuts] Knowing from documentation whether an interface is holding a pointer or a struct?

[jake...@gmail.com]

On Sunday, June 6, 2021 at 9:33:31 AM UTC-4 ren...@ix.netcom.com wrote:

> For example, the fact that this code is broken is not intuitively obvious 
> for any reader. It requires way too much scrutiny IMO. 
>
> https://play.golang.org/p/-f73t_Pm7ur 
>

I would like to note that your example goes against the general advice that 
all methods should be on either pointers or values. Mixing value and 
pointer methods for the same types is a code smell. The code you posted is 
a good example of one of the reasons why. 

The second to last paragraph in the FAQ section 
https://golang.org/doc/faq#methods_on_values_or_pointers says:
"If some of the methods of the type must have pointer receivers, the rest 
should too, so the method set is consistent regardless of how the type is 
used."

In your example, if MyEventRecorder.Log() is changed to have a pointer 
receiver, then the code works as expected: 
https://play.golang.org/p/MG10opC6Ect

-- 
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/a9b4a8b3-0b2f-4935-807e-1cbca03a3b20n%40googlegroups.com.

[go-nuts] Re: Surprising benchmark result

[jake...@gmail.com]

FWIW I do not get the same result:

goos: windows
goarch: amd64
cpu: AMD Phenom(tm) II X4 830 Processor
BenchmarkFilter3-4599912  1902 ns/op   0 
B/op  0 allocs/op
BenchmarkFilter4-4569143  2118 ns/op   0 
B/op  0 allocs/op
PASS

On Monday, June 7, 2021 at 10:57:19 AM UTC-4 tapi...@gmail.com wrote:

>
> The code: https://play.golang.org/p/DxUj6kBqf8k
>
> The Filter4 function has one more assignment statement than Filter3.
> But the benchmark result shows Filter4 is faster than Filter3.
>
> The result:
>
> cpu: Intel(R) Core(TM) i5-4210U CPU @ 1.70GHz
> BenchmarkFilter3-43575656   980.2 ns/op   0 
> B/op   0 allocs/op
> BenchmarkFilter4-43956533   916.8 ns/op   0 
> B/op   0 allocs/op
>
>
>

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

[go-nuts] Re: Are receiver copies atomic?

[jake...@gmail.com]

I'm not 100% sure what you mean by "copy made atomically" means in this 
context. But if you mean is calling a value receiver method safe for 
concurrently, then the answer is no. 

In fact it can be the source of subtle races. Take for example this simple 
program (https://play.golang.org/p/Wk5LHxEJ8dQ): 

package main
import "fmt"

type Split struct {
MutValue  uint64
CostValue uint64
}

func (s Split) GetConstValue() uint64 {
return s.CostValue
}

var Sum uint64

func main() {
theOne := Split{7, 3}
fmt.Print("Start ")

go func() {
for {
theOne.MutValue += 1
}
}()

for {
Sum += theOne.GetConstValue()
}
}

If you run this with the race detector on, you will see that there is a 
race between " theOne.MutValue += 1" and "Sum += theOne.GetConstValue()". 
At first glance it might seem like this should be ok, since the body of 
GetConstValue() only reads a non-changing variable, and does not touch MutValue 
. But in fact calling the function does a copy, and so also reads "MutValue", 
which is being concurrently modified, hence the race.  

If GetConstValue() is changed to take a pointer receiver, then the race 
goes away.   

On Tuesday, June 8, 2021 at 6:08:56 AM UTC-4 Ian Davis wrote:

> This question came to me while reading the recent thread titled "Knowing 
> from documentation whether an interface is holding a pointer or a struct?"
>
> When a method with a non-pointer receiver is called, is the copy made 
> atomically? My intuition says it must be but perhaps someone else can 
> confirm it?
>
> If so, how does it work? 
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a2ebc1d7-0a3e-4a70-a4a0-ab88fd675d34n%40googlegroups.com.

[go-nuts] Re: Question about container/heap

[jake...@gmail.com]

On Sunday, June 13, 2021 at 2:35:42 PM UTC-4 Brian Candler wrote:

> On Sunday, 13 June 2021 at 16:09:48 UTC+1 kee...@gmail.com wrote: 
>
>> For my heap, I never had to Push or Pop, I only had to initialize the 
>> heap and repeatedly "Fix" the top element of the heap.  As it turns out the 
>> Init and Fix functions only use the 3 sorting methods of the heap.  They 
>> don't use Push or Pop. So when I ran test coverage, I found that my Push 
>> and Pop implementations weren't covered.  I can't leave my Push and Pop 
>> implementation out because the Init and Fix methods require heaps with all 
>> 5 methods.  What do I do?
>
>
> Add some unit tests (in your own application) that call heap.Push or 
> heap.Pop on your heap type. That will give you the test coverage.
>
> If you don't like carrying dead code, then you could replace your Push and 
> Pop with panic() - but you'll still want unit tests that test that they 
> panic, for your coverage report.
>
> You could argue that heap.Init and heap.Fix could take a sort.Interface 
> rather than a heap.Interface.  However that exposes internals, and it would 
> limit backwards-compatible versions of those functions.
>

In fact I would go even further and argue that it would be *technically 
*incorrect 
to use the Init() and Fix() methods without fully implementing the 
interface required by the documentation. As Brian pointed out, the fact 
that they are not used is an implementation detail. Unless I missed 
something that is not documented. As a reasonable compromise, I would 
definitely implement the 'missing' methods using panic(), as a hedge 
against future changes.  I will admit, I can not really see the 
implementation changing to use Push() and Pop(), but it seems like good 
practice and hygiene. 

(I also use my car directional signals even when no one is behind me ... 
better to just keep in the habit of being safe.) 

-- 
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/10c16d77-4d05-480c-a1f3-c8c159e306c5n%40googlegroups.com.

Re: [go-nuts] Re: vendoring related question/issue

[jake...@gmail.com]

I don't use vendor, so I'm just thinking here. If I understand correctly, a 
"//go:embed" statement will cause the the target file to be included in the 
vendor. If that is the case, then perhaps you could create a 
vendored_files.go file that embeds all the files you want vendored, then 
add a build tag to the file so it never actually gets built into your 
executable?

I have not actually tried this, but it seems like it should work. 

On Thursday, June 17, 2021 at 11:25:22 PM UTC-4 Sachin Puranik wrote:

> Dear Gophers,
> I have some more thoughts about the vendoring issue I observed earlier.
>
> Preface :
> Basically while vendoring other than go files, nothing is copied in the 
> vendor folder(except the embed package).
> It can be some Readme.MD, or some text file, or HTML templates.
>
>
> Issue Details:
> In the last email, thanks to Sean, she suggested that I use the 
> https://pkg.go.dev/embed package.
> But I still see some issues.
> 1. As per package description, this will work compile-time, which means 
> the files will be embedded in the binary and affect the size of the 
> artifact.
> 2. Secondly I may want to use these files from the folder for different 
> purposes, ex: - I need not embed them, but as a part of my own build step I 
> collect all such dependencies from my module and move them to the common 
> serve folder from where they are served to the web.
> 3. it could be literally any purpose.
>
> Ultimately I think it's the purview of developers on how to use those 
> files being part of the package, hence they should not be discarded by 
> applying smart compilation.
>
>
> Now there is another associated problem, Let's say I add that manually in 
> my vendor folder, when I run  'go mod vendor', all these files are forcibly 
> deleted while updating and I am back to square one.
>
> Can you help to resolve this?
>
> Regards,
> Sachin
>
>  
>
>
> On Mon, May 10, 2021 at 10:29 AM Sachin Puranik  
> wrote:
>
>> Hi Sean,
>> Thanks for the response. Though I am not sure if the solution satisfies 
>> my use case. I am doing some experimentation and will get back to you soon 
>> with the findings.
>>
>> Thanks and Regards,
>> Sachin.
>>
>> On Sun, May 9, 2021 at 9:47 PM Sean Liao  wrote:
>>
>>> `go mod vendor` only includes what is needed to build your main module.
>>> 1.16 has https://pkg.go.dev/embed so you can embed static assets (such 
>>> as template/html files) into your final binary
>>> (they will also be available in the vendor directory but I don't think 
>>> this is your final goal)
>>>
>>> On Sunday, May 9, 2021 at 5:03:58 PM UTC+2 Sachin Puranik wrote:
>>>
 Hi Gophers,
 I noticed the following issue while vendoring the library.

 Preface :
 Basically, I created the module, for myself. This module contains 
 rendering templates and HTML files, few test files alongside the code. 
 they 
 are all tightly coupled to my module.

 Issue:
 when I use this module in another project as a vendor module, I noticed 
 that all the code files are copied well, but all my test files, HTML 
 templates, and files are completely ignored. They are not available in the 
 vendor folder.

 Kindly let me know if there is an option to achieve this, or am I doing 
 something wrong?

 Thanks in advance,
 Best regards,
 Sachin.

 -- 
>>> You received this message because you are subscribed to a topic in the 
>>> Google Groups "golang-nuts" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/golang-nuts/FAIN1fLonUc/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> golang-nuts...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/golang-nuts/66c0b083-fd53-4c96-8541-60a0fc23a581n%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/b195ade1-dede-46a5-b18c-9289a822ee4bn%40googlegroups.com.

Re: [go-nuts] unexpected stuck in sync.(*Pool).Get()

[jake...@gmail.com]

Could you clarify something? You say:
" We have about half a million agents running on each of our machines"
in your initial message. I thought maybe it was a language thing, and you 
meant 500,000 goroutines. But then you said:
"There are 7000 goroutines total"

So, you have about 500,000 *processes *running this agent on each machine, 
and each process has around 7,000 gorouines? Is that correct?

On Sunday, June 20, 2021 at 10:48:20 PM UTC-4 zjy19...@gmail.com wrote:

> On Thu, Jun 17, 2021 at 9:19 AM Peter Z  wrote: 
>> > 
>> > The original post is on stackoverflow 
>> https://stackoverflow.com/questions/67999117/unexpected-stuck-in-sync-pool-get
>>  
>> > 
>> > Golang ENV: 
>> > go1.14.3 linux/amd64 
>> > 
>> > Description: 
>> > We have about half a million agents running on each of our machines.The 
>> agent is written in Go. Recently we found that the agent may get stuck, no 
>> response for the sent requests. The metrics exported from the agent show 
>> that a channel in the agent(caching the request) is full. Deep into the 
>> goroutine stacks, we found that the goroutines consuming messages from the 
>> channel are all waiting for a lock.The goroutines Stack details are shown 
>> below. 
>>
>> That is peculiar. What is happening under the lock is that the pool 
>> is allocating a slice that is GOMAXPROCS in length. This shouldn't 
>> take long, obviously. And it only needs to happen when the pool is 
>> first created, or when GOMAXPROCS changes. So: how often do you 
>> create this pool? Is it the case that you create the pool and then 
>> have a large number of goroutines try to Get a value simultaneously? 
>> Or, how often do you change GOMAXPROCS? (And, if you do change 
>> GOMAXPROCS, why?)
>>
> 1) The GOMAXPROCS is not manually changed, it's initialized as default.
> 2) sync.Pool is not explicitly used here, we use fmt package and log 
> package
> (zap from go.uber.org/zap), which will use sync.Pool internally. 
> 3) There are 7000 goroutines total, and about 500 goroutines waiting for 
> the 
> lock, it's not much but 'create a pool and a number of goroutines 
> try go Get a value simultaneously'  may really happen on program start up. 
> 4) Does the 'taskset' command have any effect ? The program is running 
> with '*taskset* -c $last_2nd_core,$last_3rd_core,$last_4th_core'.
>
>>
>> > The stack shows that all of the goroutines are waiting for the global 
>> lock in sync.Pool. But I can't figure out which gouroutine is holding the 
>> lock. There should be a gouroutine which has `sync.runtime_SemacquireMutex` 
>> in it's stack not at the top, but there isn't. 
>>
>> I don't think that is what you would see. I think you would see a 
>> goroutine with pinSlow in the stack but with SemaquireMutex not in the 
>> stack.
>
>  
> Shown as the grep result, all of the goroutines with pinSlow have a 
> SemaquireMutex
>
> [**@** ~]$ curl **795/debug/pprof/goroutine?debug=1 
> 2>/dev/null | grep pinSlow -B4
>
> 166 @ 0x438cd0 0x4497e0 0x4497cb 0x449547 0x481c1c 0x482792 0x482793 
> 0x4824ee 0x4821af 0x520ebd 0x51fdff 0x51fcd0 0x737fb4 0x73a836 0x73a813 
> 0x97d660 0x97d60a 0x97d5e9 0x4689e1
>
> # 0x449546 sync.runtime_SemacquireMutex+0x46 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/runtime/sema.go:71
>
> # 0x481c1b sync.(*Mutex).lockSlow+0xfb 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/sync/mutex.go:138
>
> # 0x482791 sync.(*Mutex).Lock+0x271 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/sync/mutex.go:81
>
> # 0x482792 sync.(*Pool).pinSlow+0x272 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/sync/pool.go:213
>
> --
>
> 120 @ 0x438cd0 0x4497e0 0x4497cb 0x449547 0x481c1c 0x482792 0x482793 
> 0x4824ee 0x4821af 0x4f646f 0x51ed7b 0x51ff39 0x5218e7 0x73a8b0 0x97d660 
> 0x97d60a 0x97d5e9 0x4689e1
>
> # 0x449546 sync.runtime_SemacquireMutex+0x46 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/runtime/sema.go:71
>
> # 0x481c1b sync.(*Mutex).lockSlow+0xfb 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/sync/mutex.go:138
>
> # 0x482791 sync.(*Mutex).Lock+0x271 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/sync/mutex.go:81
>
> # 0x482792 sync.(*Pool).pinSlow+0x272 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/gopath/src/**/go-env/go1-14-linux-amd64/src/sync/pool.go:213
>
> --
>
> 119 @ 0x438cd0 0x4497e0 0x4497cb 0x449547 0x481c1c 0x482792 0x482793 
> 0x4824ee 0x4821af 0x5269e1 0x5269d2 0x526892 0x51f6cd 0x51f116 0x51ff39 
> 0x5218e7 0x73a8b0 0x97d660 0x97d60a 0x97d5e9 0x4689e1
>
> # 0x449546 sync.runtime_SemacquireMutex+0x46 
> /home/ferry/ONLINE_SERVICE/other/ferry/task_workspace/g

Re: [go-nuts] unexpected stuck in sync.(*Pool).Get()

[jake...@gmail.com]

Sorry, now I am completely confused. 

So, you have about 500,000 *processes *running this agent on each machine, 
>> and each process has around 7,000 gorouines? Is that correct?
>>
>
> Yes, that's  exactly what I mean. 
>

but then you say:  "Only one process per machine".

Is there a language barrier, or am I missing something?

-- 
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/e00c87d5-07b2-42ae-b295-880da866dc1cn%40googlegroups.com.

Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable

[jake...@gmail.com]

I'm surprised that I have never come across this as a way to create a slice 
with an initial length:

x := []int{100:0}

On Tuesday, June 22, 2021 at 12:43:17 PM UTC-4 axel.wa...@googlemail.com 
wrote:

> Oh and also:
>
> Likewise, I think this only works for array literals; I don’t think 
>> (though again have not tried it) that you can declare slice literals with 
>> only selected members initialized.
>
>
> Works fine too: https://play.golang.org/p/ANw54ShkTvY :)
>
> On Tue, Jun 22, 2021 at 6:41 PM Axel Wagner  
> wrote:
>
>> (I assume with a runtime rather than a compiler error, but I haven’t 
>>> tried it)
>>
>>
>> Nope, compiler catches the overflow:  
>> https://play.golang.org/p/taorqygqxFz
>>
>> On Tue, Jun 22, 2021 at 6:39 PM David Riley  wrote:
>>
>>> On Jun 22, 2021, at 11:39, Vaibhav Maurya  wrote:
>>>
>>>
>>> Hi,
>>>
>>> Please help me to understand the following syntax mentioned in the 
>>> Golang language specification document.
>>>
>>> https://golang.org/ref/spec#Composite_literals
>>>
>>> following is the search string for CTRL + F
>>> // vowels[ch] is true if ch is a vowel \
>>>
>>> Following declaration and initialization is confusing.
>>> vowels := [128]bool{'a': true, 'e': true, 'i': true, 'o': true, 'u': 
>>> true, 'y': true}
>>>
>>> Here one can see the vowels is an array. Where in the array 
>>> initialization syntax, there is a key value pair. I believe *bool *is 
>>> the primitive type, so the array values should be either true or false.
>>> Why there are key value pair separated by colon in the initialization.
>>>
>>>
>>> In this case, it is because the single quotes create a literal rune, 
>>> which ultimately is an integer; this is creating an array 128 wide of 
>>> bools, of which only the values indexed by those character values are 
>>> initialized (everything else is the zero value, or false).
>>>
>>> This example only works for characters in the 7-bit ASCII subset of 
>>> UTF-8; if you were to put other characters in which had rune values greater 
>>> than 127, this would break (I assume with a runtime rather than a compiler 
>>> error, but I haven’t tried it). Likewise, I think this only works for array 
>>> literals; I don’t think (though again have not tried it) that you can 
>>> declare slice literals with only selected members initialized.
>>>
>>>
>>> - Dave
>>>
>>> -- 
>>> 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/2564C639-E055-4DD9-97A2-9B6061F83006%40gmail.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/7d83fac1-3db0-4905-85e6-cc14b8c74389n%40googlegroups.com.

[go-nuts] Re: WinVerifyTrust WTD_STATEACTION_VERIFY wrong value

[jake...@gmail.com]

I would encourage you to file an issue 
(https://github.com/golang/go/issues), as this seems likely to be a bug. 

On Tuesday, June 22, 2021 at 8:52:58 PM UTC-4 fedegar...@gmail.com wrote:

> Hi all,
> I've been struggling a lot to replicate a C++ code that uses 
> *WinVerifyTrustEx* function in go  and I've found a discrepancy between 
> the *WTD_STATEACTION_VERIFY* value defined in the file types_windows.go 
> 
>  
> and the value defined in msdn 
> 
>  
> documentation (and sdk *WinTrust.h*).
> After changing the value to 1 in my code it started working fine. I 
> checked in master code and the issue (typo) is still present. I also 
> checked the issues in github and this one was not reported yet.
> I also notice the lack of implementation of functions 
> *WTHelperProvDataFromStateData* and *WTHelperGetProvSignerFromChain *(I 
> implemented them using the *NewLazySystemDLL *and* NewProc*), will those 
> be included in the future?
>
> Thanks in advance,
> Federico
>
>
>
>

-- 
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/617080b6-68f6-4398-8d2a-920d2706974bn%40googlegroups.com.

[go-nuts] Re: Why does one string concatenation escape, but the other not?

[jake...@gmail.com]

It does not answer your question, but possibly provides more clues: 
https://play.golang.org/p/s9Xnpcx8Mys

package main

func main() {
var a = "b"
x := a + a // does not escape
x = a + a  // does not escape
for i := 0; i < 1; i++ {
x = a + a  // a + a escapes to heap
y := a + a // does not escape
println(y)
println(x)
}
}


Only when a variable outside the loop is set inside the loop does it 
escape.  

On Wednesday, June 23, 2021 at 12:39:17 AM UTC-4 tapi...@gmail.com wrote:

>
> package main
>
> import "testing"
>
> var s33 = []byte{32: 'b'}
>
> var a = string(s33)
>
> func main() {
> x := a + a // a + a does not escape
> println(x)
> }
>
> func Benchmark_e_33(b *testing.B) {
> var x string
> for i := 0; i < b.N; i++ {
> x = a + a // a + a escapes to heap
> }
> println(x)
> }
>

-- 
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/897cf5d5-ff37-4aa7-964c-b12958a59742n%40googlegroups.com.

Re: [go-nuts] Golang language specification Document: Composite Literals example is not understandable

[jake...@gmail.com]

No that is exactly what I meant. I would never use it, as it seems like 
obfuscation, but there are those who like to be clever.

On Tuesday, June 22, 2021 at 5:36:56 PM UTC-4 Rob 'Commander' Pike wrote:

> That creates a slice 101 integers long, which probably isn't what you 
> meant, which might help explain why you never came across it before.
>
> Smile.
>
> -rob
>
>
> On Wed, Jun 23, 2021 at 7:07 AM jake...@gmail.com  
> wrote:
>
>> I'm surprised that I have never come across this as a way to create a 
>> slice with an initial length:
>>
>> x := []int{100:0}
>>
>> On Tuesday, June 22, 2021 at 12:43:17 PM UTC-4 axel.wa...@googlemail.com 
>> wrote:
>>
>>> Oh and also:
>>>
>>> Likewise, I think this only works for array literals; I don’t think 
>>>> (though again have not tried it) that you can declare slice literals with 
>>>> only selected members initialized.
>>>
>>>
>>> Works fine too: https://play.golang.org/p/ANw54ShkTvY :)
>>>
>>> On Tue, Jun 22, 2021 at 6:41 PM Axel Wagner  
>>> wrote:
>>>
>>>> (I assume with a runtime rather than a compiler error, but I haven’t 
>>>>> tried it)
>>>>
>>>>
>>>> Nope, compiler catches the overflow:  
>>>> https://play.golang.org/p/taorqygqxFz
>>>>
>>>> On Tue, Jun 22, 2021 at 6:39 PM David Riley  wrote:
>>>>
>>>>> On Jun 22, 2021, at 11:39, Vaibhav Maurya  wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> Please help me to understand the following syntax mentioned in the 
>>>>> Golang language specification document.
>>>>>
>>>>> https://golang.org/ref/spec#Composite_literals
>>>>>
>>>>> following is the search string for CTRL + F
>>>>> // vowels[ch] is true if ch is a vowel \
>>>>>
>>>>> Following declaration and initialization is confusing.
>>>>> vowels := [128]bool{'a': true, 'e': true, 'i': true, 'o': true, 'u': 
>>>>> true, 'y': true}
>>>>>
>>>>> Here one can see the vowels is an array. Where in the array 
>>>>> initialization syntax, there is a key value pair. I believe *bool *is 
>>>>> the primitive type, so the array values should be either true or false.
>>>>> Why there are key value pair separated by colon in the initialization.
>>>>>
>>>>>
>>>>> In this case, it is because the single quotes create a literal rune, 
>>>>> which ultimately is an integer; this is creating an array 128 wide of 
>>>>> bools, of which only the values indexed by those character values are 
>>>>> initialized (everything else is the zero value, or false).
>>>>>
>>>>> This example only works for characters in the 7-bit ASCII subset of 
>>>>> UTF-8; if you were to put other characters in which had rune values 
>>>>> greater 
>>>>> than 127, this would break (I assume with a runtime rather than a 
>>>>> compiler 
>>>>> error, but I haven’t tried it). Likewise, I think this only works for 
>>>>> array 
>>>>> literals; I don’t think (though again have not tried it) that you can 
>>>>> declare slice literals with only selected members initialized.
>>>>>
>>>>>
>>>>> - Dave
>>>>>
>>>>> -- 
>>>>> 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/2564C639-E055-4DD9-97A2-9B6061F83006%40gmail.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/golang-nuts/2564C639-E055-4DD9-97A2-9B6061F83006%40gmail.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> -- 
>> 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/7d83fac1-3db0-4905-85e6-cc14b8c74389n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/7d83fac1-3db0-4905-85e6-cc14b8c74389n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/2d8227ab-4053-4df4-a69b-40ba42c1645en%40googlegroups.com.

[go-nuts] Re: Upgrade to Go1.16 from Go1.14 broke my query

[jake...@gmail.com]

Is it possible that the version of the library you are using also changed 
when you changed versions of Go?
Have you tried building again, on the same machine, using Go 1.14 to make 
sure that the only difference is the Go language version?

On Thursday, June 24, 2021 at 11:14:30 AM UTC-4 hugh@gmail.com wrote:

> I recently updated my Go version to 1.16 and for all my queries I now get 
> an error:
>
> {"error":"Dynamic SQL Error\nSQL error code = -303\narithmetic exception, 
> numeric overflow, or string truncation\nstring right truncation\n"}
>
> I'm using  the package:   _ "github.com/nakagami/firebirdsql"
>
> The following is a simple function:
>
> func getSystem(w http.ResponseWriter, r *http.Request) {
> type system struct {
> Tax1float64  `json:"tax1"`
> Fees1  float64  `json:"fees1"`
> Fees2   float64  `json:"fees2"`
> Minus_stk string `json:"minus_stk"`
> Discount1 float64 `json:"discount1"`
> Discount2 float64 `json:"discount2"`
> Discount3 float64 `json:"discount3"`
> Discount4 float64 `json:"discount4"`
> Elderly float64 `json:"elderly"`
> Message NullString `json:"message"`
> Binary4 NullString `json:"binary4"`
> }
> sysdata := []system{}
> sql2 := "select tax1, fees1, fees2, minus_stk, discount1, discount2, 
> discount3, discount4, elderly, cast(mesg as varchar(400)), binary4 from 
> system"
> conn, _ := sql.Open("firebirdsql",  datapath)
> defer conn.Close()
> rows, err := conn.Query(sql2)
> if err != nil {
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
> defer rows.Close()
> for rows.Next() {
> var p system
> err := rows.Scan(&p.Tax1, &p.Fees1, &p.Fees2, &p.Minus_stk, &p.Discount1, 
> &p.Discount2, &p.Discount3, &p.Discount4, &p.Elderly, &p.Message, 
> &p.Binary4)
> if err != nil {
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
> sysdata = append(sysdata, p)
> }
> err = rows.Err()  //  <--- errors seem to thrown here.
> if err != nil {
> respondWithError(w, http.StatusBadRequest, err.Error())
> return
> }
> respondWithJSON(w, http.StatusOK, sysdata)
> }
>
> Your help would be appreciated.
>
> I'm using Firebird 2.5. Everything worked under the previous version of 
> Go. I am scanning for null values so I don't believe that is the issue.
>

-- 
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/b9ac5148-5432-4d50-a1a8-7b8de29328b4n%40googlegroups.com.

[go-nuts] Re: about golang defer?

[jake...@gmail.com]

I can't help you with your specific question, but two procedural points. 
First, while such a question is welcome in this group (golang-nuts), you 
may reach an audience better able to answer it on the golang-dev 
 group, since it deals with the 
internal details of the compiler. But I would also note that golang-dev 
 is in "Quiet Week" 
, so will be less 
active than normal. 

However you proceed, I hope you get an answer. 

On Sunday, June 27, 2021 at 10:57:17 PM UTC-4 cuiw...@gmail.com wrote:

> a defer call generate some code like:
>
>- 
>   - v42 (8) = StaticLECall  {AuxCall{runtime.deferprocStack}} 
>   [8] v36 v41
>   - v43 (8) = SelectN  [0] v42
>- Defer v42 → b2 b3 (likely) (8)
>
>
>- b2: ← b1-
>- 
>   - v48 (7) = Copy  v43
>   - v49 (7) = VarKill  {.autotmp_0} v48
>   - v50 (9) = StaticLECall  {AuxCall{runtime.deferreturn}} v49
>   - v51 (9) = SelectN  [0] v50
>   - v52 (9) = MakeResult  v51
>- Ret v52 (9)
>
>
>- b3: ← b1-
>- 
>   - v44 (8) = Copy  v43
>   - v45 (8) = StaticLECall  {AuxCall{runtime.deferreturn}} v44
>   - v46 (8) = SelectN  [0] v45
>   - v47 (8) = MakeResult  v46
>- Ret v47 (8)
>
> my question is Under what circumstances the deferprocStack return 1?
> some useful info： 
>
> https://github.com/golang/go/blob/master/src/cmd/compile/internal/amd64/ssa.go#L1287-L1289
>
> https://github.com/golang/go/blob/master/src/runtime/panic.go#L290-L328, 
> in these lines it seems deferprocStack always return 0. i think i have miss 
> some thing, please help me to find when it get to branch return 1.
>

-- 
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/1710d4fa-13a1-4846-b408-e5464a41e970n%40googlegroups.com.

[go-nuts] Re: How to pause/restart timer in a benchmark loop?

[jake...@gmail.com]

It would be helpful to give more information as to why you say "This 
doesn't work"? 
But, I'm guessing that you are not seeing a decline in times when using 
StartTimer/StopTimer.

It is likely that is because the copy function is fast, and frequent calls 
to StartTimer/StopTimer involve some error/overhead. So they are 
counteracting each other. Note that the documentation says the StopTimer 
can be used for "complex initialization", and I am guessing that a 1k copy 
does not count as complex. If you change the buffer size from 1024 to 
1024*16 then you will see that the StartTimer/StopTimer version is in fact 
faster. 

PeterGo's solution works fine, as does bench marking a larger buffer. But 
if your goal is to compare BenchmarkFilter3 and BenchmarkFilter4, then you 
could reasonably just ignore the the overhead, since it will be the same 
for both functions. 

On Wednesday, July 7, 2021 at 11:29:30 AM UTC-4 tapi...@gmail.com wrote:

> This doesn't work:
>
> func BenchmarkFilter3(b *testing.B) {
> data := buildOrginalData()
> data2 := make([]int, len(data))
> b.ResetTimer()
> for i := 0; i < b.N; i++ {
> b.StopTimer()
> copy(data2, data)
> b.StartTimer()
> _ = Filter3(data2)
> }
> }
>
> On Wednesday, July 7, 2021 at 11:28:13 AM UTC-4 tapi...@gmail.com wrote:
>
>>
>> For example, I don't want the time consumed for "copy(data2, data)" being 
>> counted.
>> How to achieve this?
>>
>> func BenchmarkFilter3(b *testing.B) {
>> data := buildOrginalData()
>> data2 := make([]int, len(data))
>> b.ResetTimer()
>> for i := 0; i < b.N; i++ {
>> copy(data2, data)
>> _ = Filter3(data2)
>> }
>> }
>>
>

-- 
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/c1f156d5-e582-4932-88f8-a2df6c987d85n%40googlegroups.com.

Re: [External] Re: [go-nuts] build debug golang

[jake...@gmail.com]

On Thursday, July 8, 2021 at 11:45:19 PM UTC-4 Ian Lance Taylor wrote:

> On Thu, Jul 8, 2021 at 8:41 PM 董⼀峰  wrote: 
> > 
> > Thanks for replying. 
> > So golang only supports debugging optimized golang runtime? 
>
> Well, Go requires that the runtime package be built with optimization 
> (when using the gc compiler, which is the default). So, yes, when 
> running runtime code under the debugger you will be looking at 
> optimized code. 
>

Is this just to keep people from accidentally making a slow version of the 
runtime, or is there an actual technical reason why it would not work?  If 
the check were removed 
(https://github.com/golang/go/blob/ef57834360cf69f2e8b52b32c7a05d96bf6bbba7/src/cmd/compile/internal/base/flag.go#L226)
 
is there any reason to believe that the runtime would not function 
correctly (albeit slowly)? 

-- 
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/37425499-16b7-4569-bad9-55fd45c1bff6n%40googlegroups.com.

Re: [External] Re: [go-nuts] build debug golang

[jake...@gmail.com]

Thanks Ian. 
Makes sense now. I was scratching my brain to figure out possible ways that 
lack of optimization could cause actual failures.The Go team does an 
amazing job.

On Friday, July 9, 2021 at 11:02:59 PM UTC-4 Ian Lance Taylor wrote:

> On Fri, Jul 9, 2021 at 8:33 AM jake...@gmail.com  
> wrote:
> >
> > On Thursday, July 8, 2021 at 11:45:19 PM UTC-4 Ian Lance Taylor wrote:
> >>
> >> On Thu, Jul 8, 2021 at 8:41 PM 董⼀峰  wrote:
> >> >
> >> > Thanks for replying.
> >> > So golang only supports debugging optimized golang runtime?
> >>
> >> Well, Go requires that the runtime package be built with optimization
> >> (when using the gc compiler, which is the default). So, yes, when
> >> running runtime code under the debugger you will be looking at
> >> optimized code.
> >
> >
> > Is this just to keep people from accidentally making a slow version of 
> the runtime, or is there an actual technical reason why it would not work? 
> If the check were removed (
> https://github.com/golang/go/blob/ef57834360cf69f2e8b52b32c7a05d96bf6bbba7/src/cmd/compile/internal/base/flag.go#L226)
>  
> is there any reason to believe that the runtime would not function 
> correctly (albeit slowly)?
>
> Yes, there are cases that will fail if the runtime is compiled without
> optimization. The Go compiler and runtime cooperate to ensure that
> there is a certain amount of stack space available at all times.
> Certain parts of the runtime can't copy the stack for various reasons
> (these functions are marked with "//go:nosplit" in the runtime Go code
> and with NOSPLIT in the runtime assembly code). Those parts of the
> runtime are constrained to run within the amount of stack space that
> is always available. When the runtime is compiled without
> optimization, functions use more stack space, and in some cases there
> are sequences of nosplit function calls that run over the amount of
> stack space they have available.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/81f1df27-43e3-4eae-8d5e-a60141a844f5n%40googlegroups.com.

[go-nuts] Re: how to create array of structures instances for the nested structures

[jake...@gmail.com]

Some ways to do it:

https://play.golang.org/p/sg08Buv-E3-

Note that arrays are rarely used in Go. When in doubt, default to using a 
slice. I provided  slice examples as well. 
If you want to initialize a very large array or slice to a value other than 
the zero value, you could also use a loop. 


On Wednesday, July 14, 2021 at 11:32:13 AM UTC-4 trivedi...@gmail.com wrote:

> Hi all, it would be helpful for me if a small doubt of mine is resolved.
>
> I want to know how to create an array of structure instances  for a nested 
> structure. Let me write it
>
> type Strct1 struct {
> val1 int
>  val2 int
> }
> type Strct2 struct {
>  Namce string
>   temp Strct1
> }
> I want to create an array of instances for Strct2 and initialise it. 
> Please let me know how to do it.
>
> Thanks
> Nagaraj
>  
>  
>

-- 
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/82a85bf1-a2ac-4e35-a40e-00fb7d337ba2n%40googlegroups.com.

[go-nuts] Re: How to Optimize A Golang Application Which Has More Than 100 Million Objects at Peak?

[jake...@gmail.com]

Two other replies have mentioned Sync.Pool. I agree that Sync.Pool is a 
valuable tool. 

However, for the benefit of any beginning gophers who may read this thread, 
I wanted to point out that, in a situation like yours, I would want to try 
to reduce heap allocation in other ways first. Not that Sync.pool is a last 
resort exactly, but it does have non-trivial overhead, and is not a 
substitute for thinking about other ways to clean up heap allocations. For 
example, pulling allocations out of loops, or manual object re-use where it 
fits naturally into the code.

On Friday, July 16, 2021 at 8:27:03 AM UTC-4 rmfr wrote:

> I run it at an 8 cores 16GB machine and it occupies all cpu cores it could.
>
> 1. It is ~95% cpu intensive and with ~5% network communications.
>
> 2. The codebase is huge and has more than 300 thousands of lines of code 
> (even didn't count the third party library yet).
>
> 3. The tool pprof tells nearly 50% percent of the time is spending on the 
> runtime, something related to gc, mallocgc, memclrNoHeapPointers, and so on.
>
> 4. It has ~100 million dynamic objects.
>
> Do you guys have some good advice to optimize the performance?
>
> One idea that occurs to me is to do something like sync.Pool to buffer 
> some most frequently allocated and freed objects. But the problem is I 
> didn't manage to find a golang tool to find such objects. The runtime 
> provides api to get the amount of objects but it didn't provide api to get 
> the detailed statistics of all objects. Please correct me if I'm wrong. 
> Thanks a lot :-)
>

-- 
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/512e7d48-3ee3-48c8-8a64-5118a341e6aen%40googlegroups.com.

[go-nuts] Re: Out of memory using golang.org/x/tools/go/packages

[jake...@gmail.com]

The first thing I would do is remove the call to litter, and see if that 
solved the issue. That would tell you immediately if the problem was the 
litter package or the packages package. I have so specific knowledge, but 
it is not impossible to imagine that you are simply trying to print 
something way to big for litter. 

After that, using pprof might be your next step.

Have you tried it on a really tiny package?

On Wednesday, July 21, 2021 at 6:41:39 AM UTC-4 mlevi...@gmail.com wrote:

> Hi all,
>
> I'm having a very hard time with golang.org/x/tools/go/packages. Spent 
> most of my evening yesterday trying to understand what's happening here.
> Here's my code: https://play.golang.com/p/5L1N0lSaetB
>
> With this very simple code I would expect that the program prints detailed 
> information about the package path I run it with. But whatever the package, 
> or module, I try to use this with, the program is killed because it takes 
> all the memory (~32GB) of my machine in a few seconds, nothing ever gets 
> printed...
>
> Here's my config: 
> GO111MODULE=""
> GOARCH="amd64"
> GOBIN=""
> GOCACHE="/home/michel/.cache/go-build"
> GOENV="/home/michel/.config/go/env"
> GOEXE=""
> GOFLAGS=""
> GOHOSTARCH="amd64"
> GOHOSTOS="linux"
> GOINSECURE=""
> GOMODCACHE="/home/michel/.go/pkg/mod"
> GONOPROXY=""
> GONOSUMDB=""
> GOOS="linux"
> GOPATH="/home/michel/.go"
> GOPRIVATE=""
> GOPROXY="https://proxy.golang.org,direct";
> GOROOT="/usr/local/go"
> GOSUMDB="sum.golang.org"
> GOTMPDIR=""
> GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
> GOVCS=""
> GOVERSION="go1.16"
> GCCGO="gccgo"
> AR="ar"
> CC="gcc"
> CXX="g++"
> CGO_ENABLED="1"
> GOMOD="/dev/null"
> CGO_CFLAGS="-g -O2"
> CGO_CPPFLAGS=""
> CGO_CXXFLAGS="-g -O2"
> CGO_FFLAGS="-g -O2"
> CGO_LDFLAGS="-g -O2"
> PKG_CONFIG="pkg-config"
> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
> -fdebug-prefix-map=/tmp/go-build3825502007=/tmp/go-build 
> -gno-record-gcc-switches"
>
>
> I have tried many, many things yesterday, including:
> - changing the `Mode` in the config
> - using go/types directly ("can't find import" for the package I'm look to 
> parse)
> - using different importers
> - trying to load and parse different packages
> - ...
>
> For context, and to avoid any XY problem here, my goal is to parse a 
> package and find an interface based on its name. Once this interface is 
> found, I need to range over its method set and generate a structure 
> implementing this interface, with (maybe not at the beginning but) a lot of 
> logic, e.g. detect that an interface returns an implementation of itself, 
> and so on.
> I'm working on a tool to generate mock structures from their interface 
> method set, as a personal project, and this is kind of the most important 
> part of it (being able to automatically generate the mock).
>
> If anyone would kindly help me find what I'm doing wrong, or at least 
> point me to useful resources explaining how to fix my problem, I would be 
> reaally delighted. This has been a problem for days now... And I can't 
> find any relevant issue or blog as this is a peculiar context.
>
> Thanks in advance to all that will read this and have a nice day! :D
>

-- 
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/36cd11af-ee05-4e9e-8324-51212c80d99cn%40googlegroups.com.

[go-nuts] Re: A peculiar sort problem

[jake...@gmail.com]

Personally I would be careful about assuming that was the only sorting 
difference. Unless you have checked every Unicode character, there could be 
other hidden 'special cases'. If it *really *mattered, personally, I would 
dig into the .NET library source code and see what algorithm or system call 
is used to sort. You may even be able to use the same system call (assuming 
you are on Windows only) or algorithm. 

On Tuesday, July 27, 2021 at 1:57:07 PM UTC-4 amplep...@gmail.com wrote:

> Hi! 
>
> I am writing a tool that handles files and generates some sorted
> output. Since this tool is to be a replacement for part of
> another system (written in C#/.NET), the output must be a
> byte-exact duplicate.
>
> The existing system generates some checksums and filenames in a
> stable sorted order, like so (also pastebinned at
> https://dpaste.org/MLMv):
>
> ```
> addons/rhs_bmp.pbo 2D08606D9BCB43E37A44CDBCD753F663
> addons/rhs_bmp.pbo.rhsafrf.0.5.6.bisign 4F0BAAFDDC2C3474F7B310BAF221C22E
> addons/rhs_bmp_camo.pbo 5A9AED2283EE8B8E55BE07772CB9EF33
> addons/rhs_bmp_camo.pbo.rhsafrf.0.5.6.bisign 
> C5638F6DC62DED7C05877896096BE7CC
> addons/rhs_bmp3.pbo 1F8E4520CA673FE5F67E434D6C9C3EAA
> addons/rhs_bmp3.pbo.rhsafrf.0.5.6.bisign
> addons/rhs_bmp3_camo.pbo CE25F0037BCD19F55D6AA1CD3AEA0B86
> addons/rhs_bmp3_camo.pbo.rhsafrf.0.5.6.bisign 
> 9CF15ED151231E6C1E8A5E63C5AAD829
> addons/rhs_btr70.pbo 7FCC93BDDBE1A0573ABF146FA7C1FAD9
> addons/rhs_btr70.pbo.rhsafrf.0.5.6.bisign 61FD5A3D99F6A60BB31F0D396B19E5C5
> addons/rhs_btr70_camo.pbo 9A8F2BF875276FA1F7018F2D60C89D7A
>
> ```
>
> My tool works just fine, except it disagrees on the sorting
> (pastebinned at https://dpaste.org/UDiK):
>
> ```
> addons/rhs_bmp.pbo 2D08606D9BCB43E37A44CDBCD753F663
> addons/rhs_bmp.pbo.rhsafrf.0.5.6.bisign C5638F6DC62DED7C05877896096BE7CC
> addons/rhs_bmp3.pbo 1F8E4520CA673FE5F67E434D6C9C3EAA
> addons/rhs_bmp3.pbo.rhsafrf.0.5.6.bisign 2CCF421E08170964CF323A98725DDA6E
> addons/rhs_bmp3_camo.pbo CE25F0037BCD19F55D6AA1CD3AEA0B86
> addons/rhs_bmp3_camo.pbo.rhsafrf.0.5.6.bisign 
> 4F0BAAFDDC2C3474F7B310BAF221C22E
> addons/rhs_bmp_camo.pbo 5A9AED2283EE8B8E55BE07772CB9EF33
> addons/rhs_bmp_camo.pbo.rhsafrf.0.5.6.bisign 
> 9CF15ED151231E6C1E8A5E63C5AAD829
> addons/rhs_btr70.pbo 7FCC93BDDBE1A0573ABF146FA7C1FAD9
> ```
>
> In essence, to the .NET program `_` sorts before `3`, whereas for
> my Go program, it is the other way around.
>
> Now we could discuss at length which order is the correct one,
> but for my purposes (replicating the .NET tool) is what I
> strongly prefer. The alternative would be a breaking change in a
> larger system I do not control, and as such would be a lot of
> pain.
>
> So my question is: what is the easiest way to tell Go that `_`
> sorts before numerals here? My current sort helpers are (on the
> playground: https://play.golang.org/p/pQLeZN-fptY):
>
> ```
> type Files []ModFile
> type ModFile struct {
> Path string
> // Other fields here
> }
> func (f Files) Len() int { return len(f) }
> func (f Files) Swap(i, j int) { f[i], f[j] = f[j], f[i] }
> func (f Files) Less(i, j int) bool { return strings.ToLower(f[i].Path) < 
> strings.ToLower(f[j].Path) }
> ```
>
> (yes, the case folding is another peculiarity of the .NET tool)
>
> Best,
> Tobias
>

-- 
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/98eed7b6-4b1e-4ba5-a457-141ae5daca52n%40googlegroups.com.

Re: [go-nuts] use delve to debug golang with 'next' will skip some step

[jake...@gmail.com]

Was the code built with optimizations disabled?

On Tuesday, July 27, 2021 at 1:57:17 PM UTC-4 林 子鹏 wrote:

> When I use delve to debug this project(dlv debug t.go): 
>
> //t.gopackage main
> import (
> "fmt"
> "os"
> "reflect"
> "unsafe"
> )
> func main() {
> s1 := make([]uint8, 0)
> aboutSlice(&s1, "s1")
> s2 := make([]uint8, 8)
> aboutSlice(&s2, "s2")
> new_s1 := append(s1, 10)
> new_s2 := append(s2, 20)
> aboutSlice(&new_s1, "new_s1")
> aboutSlice(&new_s2, "new_s2")
> os.Exit(0)
> }
> func aboutSlice(s *[]uint8, n string) {
> fmt.Printf("%s:\tmem_addr:%p\tsize:%v\taddr:%#x\tlen:%v\tcap:%v\n", n, s, 
> unsafe.Sizeof(*s), (*reflect.SliceHeader)(unsafe.Pointer(s)).Data, len(*s), 
> cap(*s))
> }
>
> I want to analyze the behavior of function growslice(in 
> runtime/slice.go),and then set breakpoints on func growslice,I use n and s 
> to analyze it, but it will skip some step, like the picture below:
>

-- 
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/092abda0-72ba-429d-96df-60faf570198fn%40googlegroups.com.

[go-nuts] Re: What does io.Closer.Close do?

[jake...@gmail.com]

Just to clarify, the statement " Close will return an error if it has 
already been called"  on  os.File.Close  
is explicitly not the behavior guaranteed by io.Closer 
, which specifically states: " The behavior 
of Close after the first call is undefined. Specific implementations may 
document their own behavior." 

My understanding is that this is the result of a historical oversight, but 
can not be changed now. 

On Tuesday, August 10, 2021 at 2:46:12 AM UTC-4 Brian Candler wrote:

> It's for file-like objects that should be closed when they're no longer 
> being used, in order to reclaim resources promptly.  The details depend on 
> the underlying type, but see for example os.File.Close 
> :
>
> "Close closes the File, rendering it unusable for I/O. On files that 
> support SetDeadline, any pending I/O operations will be canceled and return 
> immediately with an error. Close will return an error if it has already 
> been called."
>
> On Tuesday, 10 August 2021 at 02:13:30 UTC+1 i...@iangudger.com wrote:
>
>> io.Closer simply says "Closer is the interface that wraps the basic Close 
>> method," but does not document its Close method.
>>
>> Effective Go says:
>> "There are a number of such names and it's productive to honor them and 
>> the function names they capture. Read, Write, Close, Flush, String and so 
>> on have canonical signatures and meanings. To avoid confusion, don't give 
>> your method one of those names unless it has the same signature and 
>> meaning." (https://golang.org/doc/effective_go#interface-names)
>> ...but does not elaborate on what the canonical meanings are.
>>
>> So what is the canonical meaning of a Close method?
>>
>

-- 
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/97072cbf-1b98-474b-8484-4e0546f1d8a0n%40googlegroups.com.

[go-nuts] Re: how golang stores variables in the computer’s memory?

[jake...@gmail.com]

It will also help you look knowledgeable if you refer to the language as 
Go, never `golang`. The name of the language is just 'Go'. In my experience 
the term golang should only be used when you need to clarify for a search 
engine. 

I don't usually bother correct people on this issue, but given the context 
of your question it seemed appropriate. 

On Tuesday, August 17, 2021 at 2:39:30 AM UTC-4 Miraddo wrote:

> Hello, 
>
> Yesterday, I had an awesome interview, and I found I don't know anything 
> about  `Golang`  in deep, so I decided to learn more about the compiler and 
> memory and every part of  `Golang`  in deep. I guess I had a lot of 
> questions :)
>
> Do you have any reference to know, How `Golang` stores' variables in 
> memory ?
>
> How does `Golang` point a variable to the memory location, and how is 
> reference stored?
>
> And any suggestion it would be helpful for me, what should I do to learn 
> more deep concepts.
>
> Thank you,
> Milad
>

-- 
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/560bd28c-0e4b-429a-aa11-8f6109a407efn%40googlegroups.com.

[go-nuts] Re: Whats wrong with my channel

[jake...@gmail.com]

Jan is correct, and you should probably use a sync.WaitGroup to keep your 
main() alive.

But even if you do that, you have a bigger problem. You channel is 
unbuffered. That means that `d <- a` will block until someone reads from d. 
Since `factorial` is the only goroutine that uses d, that line will block 
forever. (Of course, in your code, main() will exit after 3 seconds, so 
forever is short.) You can 'fix' the code by changing to a buffered 
channel, like: `d := make(chan int, 1)`. Then your code works, since the 
send will no longer block. Although it is pretty pointless to read from a 
channel in the same goroutine that writes to it.

A more common use would be for the goroutine to send the result back to 
main, like this: https://play.golang.org/p/yJHJWhYif5h
Note that, in this case, the channel read keeps main() from exiting before 
factorial() is finished.

On Thursday, August 19, 2021 at 10:43:32 AM UTC-4 muhorto...@gmail.com 
wrote:

> I just started practicing with channels, after writing to the channel, 
> nothing is output from there
> func main() {
> d := make(chan int)
> go factorial(5, d)
>  time.Sleep(3 * time.Second)
> }
>
> func factorial(n int, d chan int) {
> fmt.Println("function starting...")
> time.Sleep(3 * time.Second)
> var a int = 1
> for ; n > 0; n-- {
> a *= n
> }
> d <- a // //nothing works after that
> fmt.Println(<-d)
> fmt.Println(a)
> }
>
> 
> Another question I want to make a recursive function with a factorial, 
> pass it to goroutine in main. But I do not know if it is possible to 
> somehow combine *return* and a channel in the declaration of arguments.
>
> -
> if I first pass in something to the channel from main,
> a lock occurs.Why? So it's not possible at all?
>

-- 
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/e81505fe-3415-4eb0-acf0-4b208e42fa13n%40googlegroups.com.

[go-nuts] Re: Makefiles for Go Programs

[jake...@gmail.com]

On Sunday, August 22, 2021 at 11:11:23 PM UTC-4 jlfo...@berkeley.edu wrote:

>
> I've noticed that few, if any, Go programs use Makefiles. Is that because 
> the overhead of using make is greater than the overhead of just always 
> compiling and linking everything?
>
 
Go had built in build caching. So it will not have to "always compile and 
link everything." In addition, Go builds tend to be much, much faster than 
most other compiled languages. As a result, Makefiles are only useful if 
you have other operations to perform that are not part of the normal go 
tooling. 
 

> One piece of evidence for this is that the Go compiler leaves no 
> artifacts, like object files, so as is make wouldn't fit into the current 
> build method.
>
> Cordially,
> Jon Forrest
>
>
>

-- 
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/449781bc-1605-4acf-b03c-dab98cf710efn%40googlegroups.com.

Re: [go-nuts] Function to escape and unscape string

[jake...@gmail.com]

 https://pkg.go.dev/strconv#Unquote seems to be what you are describing. 
Perhaps you could explain *how *it fails to do what you want. Maybe a 
playground  example? 


On Sunday, August 29, 2021 at 3:53:02 PM UTC-4 nadashin wrote:

> > > fmt.Printf has a format specifier, %q that escapes string with Go
> > > syntax and add quotes around the string. ( %#v also does it)
> > >
> > > But it doesn't have one that unescapes a string.
> > >
> > > I couldn't find any stdlib function that escape and unescape a string
> > > following Go syntax. (and doesn't add quotes around the string)
> >
> > Maybe https://pkg.go.dev/strconv#Unquote is what you want.
>
> No, that's not what I am looking for.
>

-- 
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/6304ea5d-6f13-4001-aaf4-c3be00fdf4d0n%40googlegroups.com.

[go-nuts] Re: Function to escape and unscape string

[jake...@gmail.com]

On Sunday, September 5, 2021 at 12:56:07 AM UTC-4 tapi...@gmail.com wrote:

> This is a known problem: https://github.com/golang/go/issues/8618
> I looks the root cause is reflect.TypeOf and ValueOf make the values 
> referenced by the arguments escape, though often this is over-cautious.
>

I think you misunderstood the problem. The question  has to do with 
character escaping in strings, not memory escaping to the heap.

Of course we don't actually know what the problem the OP is having with 
escaping strings, because the original post is vague.  

On Sunday, August 29, 2021 at 3:02:42 PM UTC-4 nadashin wrote:
>
>> fmt.Printf has a format specifier, %q that escapes string with Go 
>> syntax and add quotes around the string. ( %#v also does it) 
>>
>> But it doesn't have one that unescapes a string. 
>>
>> I couldn't find any stdlib function that escape and unescape a string 
>> following Go syntax. (and doesn't add quotes around the string) 
>>
>>

-- 
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/f68eaf4e-341e-485e-80a8-8e7c91970969n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[jake...@gmail.com]

Like Brian, I think part of he problem is possibly a miscommunication based 
on "monotonically increasing". The term means that each point is greater 
than, *or equal to*, the previous one. 
https://en.wikipedia.org/wiki/Monotonic_function. In other words, it never 
decreases. In the example given  (https://play.golang.org/p/RJbEkmFsPKM 
), the capacities *are *"monotonically 
increasing", as no number in the second column is smaller than the one 
before it. 

On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:

> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote:
> > I'm not sure you're clear about what "monotonically increasing"
> > means.
> >
> > Are you saying that there are some cases where append() results in
> > the allocated size of a slice *shrinking*? If so, please
> > demonstrate.
>
> I think he means that the cap of the appended slice is not a
> monotonically increasing function of the cap of the input slice.
>
> https://play.golang.org/p/RJbEkmFsPKM
>
>
>

-- 
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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%40googlegroups.com.

Re: [go-nuts] Re: slices grow at 25% after 1024 but why 1024?

[jake...@gmail.com]

You are 100% correct. I missed that value. oops

On Sunday, September 5, 2021 at 10:16:08 AM UTC-4 arn...@gmail.com wrote:

>
>
> On Sun, 5 Sep 2021, 14:59 jake...@gmail.com,  wrote:
> [...]
>
>> In the example given  (https://play.golang.org/p/RJbEkmFsPKM 
>> <https://play.golang.org/p/RJbEkmFsPKM>), the capacities *are 
>> *"monotonically 
>> increasing", as no number in the second column is smaller than the one 
>> before it.
>>
>  
> Nitpick: that is not true.  I copy-pasted the output of the playground 
> below.
>
> 0 8
> 100 208
> 200 416
> 300 640
> 400 896
> 500 1024
> 600 1280
> 700 1408
> 800 1792
> 900 2048
> 1000 2048
> 1100 1408 <-- at this point the new cap is less than for the previous row
> 1200 1536
> 1300 1792
> 1400 1792
> 1500 2048
> 1600 2048
> 1700 2304
> 1800 2304
> 1900 2688
>
> Regards,
>
> Arnaud
>
> On Sunday, September 5, 2021 at 7:02:43 AM UTC-4 kortschak wrote:
>>
>>> On Sun, 2021-09-05 at 03:51 -0700, Brian Candler wrote: 
>>> > I'm not sure you're clear about what "monotonically increasing" 
>>> > means. 
>>> > 
>>> > Are you saying that there are some cases where append() results in 
>>> > the allocated size of a slice *shrinking*? If so, please 
>>> > demonstrate. 
>>>
>>> I think he means that the cap of the appended slice is not a 
>>> monotonically increasing function of the cap of the input slice. 
>>>
>>> https://play.golang.org/p/RJbEkmFsPKM 
>>>
>>>
>>> -- 
>> 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/912453d5-2f2f-43b2-b65f-ce27e95752e9n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/912453d5-2f2f-43b2-b65f-ce27e95752e9n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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/4a8d72c1-9f31-48e1-bf08-0022bc11543fn%40googlegroups.com.

Re: [go-nuts] How to check whether a variable is unreachable?

[jake...@gmail.com]

I'm pretty sure new example is not valid Go code to begin with. You violate 
the rules on converting from uintptr to unsafe.Pointer. If you read the 
rules at https://pkg.go.dev/unsafe#Pointer, a unitptr can not *generally *be 
converted to an unsafe.Pointer. Since this code is not valid, the question 
is pretty much moot.

On Thursday, September 23, 2021 at 2:23:47 AM UTC-4 chole...@gmail.com 
wrote:

> Thanks, I see. How about this one? I use a temp variable to store sh.Data, 
> sh/ds/data are all no longer mentioned at the point when unsafe.Slice is 
> called. Do I need to use runtime.KeepAlive? 
>
> package main
>
> import (
> "fmt"
> "reflect"
> "runtime"
> "unsafe"
> )
>
> var b []byte
>
> func f(data interface{}) {
> switch ds := data.(type) {
> case []int32:
> sh := (*reflect.SliceHeader)(unsafe.Pointer(&ds))
> l := len(ds)
> d := sh.Data
> runtime.GC()
> b = unsafe.Slice((*byte)(unsafe.Pointer(d)), l*4)
> }
> // runtime.KeepAlive(data)
> }
>
> func main() {
> f([]int32{1, 2})
> runtime.GC()
> fmt.Println(b)
> }
>
> 在2021年9月23日星期四 UTC+8 上午6:11:48 写道：
>
>> On Wed, Sep 22, 2021 at 1:22 AM Cholerae Hu  wrote: 
>> > 
>> > https://play.golang.org/p/WJTH-lUukeb 
>> > 
>> > Do I need to uncomment line 23? IMHO, variable data and ds will not be 
>> used after line 16, so they can be collected in runtime.GC. But running it 
>> with gccheckmark=1 and clobberfree=1 doesn't show any problems. 
>> > 
>> > Are there any documents about the details or behavior of liveness 
>> analysis? 
>>
>> I don't see any reason why that program should need runtime.KeepAlive. 
>>
>> The local variable sh will point to data (aka ds), so the object will 
>> stay alive. This is not different than p := &data. After that point, 
>> if data is no longer mentioned, then the variable data is no longer 
>> live, but the value that p points to will remain alive. 
>>
>> Ian 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a230e4be-a162-4385-9aab-99dadc25d061n%40googlegroups.com.

[go-nuts] Re: Trouble with pgx package

[jake...@gmail.com]

If you want to know what the error is, I suggest you print it. That will 
give you more information. It will also help anyone trying to help you.

Also, I notice that you *probably *have 
"defer conn.Close(context.Background())" in the wrong place.* I don't use 
pgx*, but the normal paradigm is to add the defer(Close) immediately after 
a successful opening or creation of the resource. So in the sample code you 
give, that would be right after the Connect and the error check. Like this: 

conn, err := pgx.Connect(context.Background(), connStr)
if err != nil {
fmt.Fprintf(os.Stderr, "Unable to connect to database: %v\n", err)
os.Exit(1)
}
defer conn.Close(context.Background()) 

The way you have it written, if there is an error on QueryRow() then the 
connection is never closed. 
On Saturday, October 2, 2021 at 6:52:44 AM UTC-4 muhorto...@gmail.com wrote:

> Just started making my first web, I don't quite understand the Query Row 
> function. An error is returned, I process it. What is the error?
> func save(w http.ResponseWriter, r *http.Request) {
> login := r.FormValue("login")
> password := r.FormValue("password")
> if login == "" || password == "" {
> fmt.Fprint(w, "Не все данные введены")
> }
> conn, err := pgx.Connect(context.Background(), connStr)
> if err != nil {
> fmt.Fprintf(os.Stderr, "Unable to connect to database: %v\n", err)
> os.Exit(1)
> }
>
> err := conn.QueryRow(context.Background(), "INSERT INTO users (login, 
> password) VALUES ($1, $2)", login, password)
> if err != nil {
> return err
> }
> defer conn.Close(context.Background())
> http.Redirect(w, r, "/", http.StatusSeeOther)
> }
>

-- 
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/2586d26c-d508-490e-b05c-f0f9ffb359fdn%40googlegroups.com.

[go-nuts] Re: Why Doesn't "len()" Work With Structs?

[jake...@gmail.com]

On Sunday, October 24, 2021 at 7:44:40 PM UTC-4 jlfo...@berkeley.edu wrote:

> Thanks for the replies.
>
> I had been trying to translate the trick from C into Go where you can find 
> how many structures are in an initialized array of structures
> by dividing the size of the array by the size of one structure. As I've 
> learned, not only isn't this possible, because you can't get
> the size of one structure, but also because it isn't necessary. Instead, 
> using a slice of structures rather than an array, I can just do 
> "len(structslice)".
> That gives me what I need. 
>

You don't even need to use "a slice of structures rather than an array", 
since len() works just fine with arrays. See 
https://play.golang.org/p/I71I-5DlGKH. 

But it is unclear why you want to get the number of elements in an array. 
In Go, if you have an array, you always know the size. Perhaps an example 
would help?

You may be used to using arrays in other languages. But in Go arrays are 
rarely used. In the vast majority of cases slices are preferred. This is, 
in part, because arrays in Go are values. When you assign one array to 
another, or when you pass an array to a function, the entire contents are 
copied. As you can imagine, this can be quite expensive. That is not to say 
that arrays should never be used in Go, but a slice should be your default 
go to, unless you have a real need for the value (copy ) semantics of an 
array, or have another compelling reason.


> But, I still have some questions about the responses. First, I think the 
> expected value of len(struct) should be its size, in bytes,
> like with a string. Are there any examples of problems this would cause? I 
> don't understand why this has to be
> unsafe. (It could even be done at compile time). I also don't understand 
> the comment about recursive calls. Since it's possible
> to assign one structure to another I would think that the structure length 
> is known. Since I'm new to Go I'm probably
> not aware of the finer points that would make this not so.
>
> Cordially,
> Jon Forrest
>
> On Sunday, October 24, 2021 at 11:29:58 AM UTC-7 filipdimi...@gmail.com 
> wrote:
>
>> len() works on indexed types - arrays, slices, maps, strings. It also 
>> works on buffered channels but we can consider that a sequence. I don't 
>> consider a struct a sequence. It's non-obvious what the behaviour would be. 
>> Both of these sound reasonable: len() should be the memory size of the 
>> struct like sizeof in C/C++ *or* it should be the sum of the lengths of its 
>> (sequence) members.
>>
>> The first case is way too low-level for Go, because it belongs to an 
>> unsafe operation so that's an easy no, ... and it already exists as 
>> unsafe.Sizeof().
>>
>> The second case (len being the sum of its members' lengths) would require 
>> recursive calls, and almost surely infinite cycles as we eventually get to 
>> pointers. 
>>
>> On Sunday, October 24, 2021 at 8:11:37 PM UTC+2 jlfo...@berkeley.edu 
>> wrote:
>>
>>> I noticed that the len() function doesn't take a struct as an argument 
>>> (see below).
>>> This is a big surprise. Can someone shed some light on why this 
>>> restriction exists?
>>>
>>> Cordially,
>>> Jon Forrest
>>>
>>> --
>>> package main
>>>
>>> import "fmt"
>>>
>>> var s struct {
>>> i1  int
>>> i2  int
>>> }
>>>
>>> func main() {
>>>fmt.Printf("len(s) = %d\n", len(s)) // -- invalid argument s 
>>> (type struct { i1 int; i2 int }) for len
>>> }
>>>
>>

-- 
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/b03522a1-6fb9-46b1-bbc3-2d1cc12158ban%40googlegroups.com.

Re: [go-nuts] Which error handling pattern do you prefer?

[jake...@gmail.com]

On Friday, November 12, 2021 at 6:29:46 PM UTC-5 michael...@gmail.com wrote:

> FWIW (which may not be much) I've settled on explicitly naming my return 
> values in the function declaration.  If the function returns include an 
> error, I name always name it err. The general pattern is
>
> func foo() (v someType, err error) {
>   err = doSomething()
>   if err != nil {
> err = fmt.Errorf("some context: %v", err)
> return
> }
>   err = doNextThing()
>   if err != nil {
>  err = fmt.Errorf("some context: %v", err)
>  return
>   }
> // etc
> return
> }
>
>  
As Brian mentioned above, naked return values are generally frowned upon. 
You can easily find the arguments if you like, but even the official tour 
of go (at https://tour.golang.org/basics/7)  says: 

"Naked return statements should be used only in short functions, as with 
the example shown here. They can harm readability in longer functions."

That's a pretty official caution. Personally, I am very much in that camp. 
In my experience, naked returns harm readability in all cases, just less in 
short functions.

So this is probably not a good pattern to use as your default one. 

 

> Naming the error solves the initial := problem.  As for shadowing, I make 
> it a point never to do a := assignment involving err. For example, if I 
> need to call os.Open, I do
>
> var f *os.File
> f, err = os.Open(...)
>
> I tend to use other names for errors only when it's something I can fix 
> within the local scope.
>
> At first I tried hard to avoid the verbosity.  Now I use a few helpful 
> snippets to reduce keystrokes and an editor plugin the partially fades any 
> block that starts with "if err != nil".  The latter works amazingly well 
> (for me at least) to reduce visual clutter.  I like it much better than one 
> I tried that auto-folds error blocks.  It made me waste time unfolding them 
> to see what was inside :-)
>
> YMMV, of course.
>
> On Friday, November 12, 2021 at 11:15:21 AM UTC-5 david@gmail.com 
> wrote:
>
>> On Fri, Nov 12, 2021 at 7:48 AM Miguel Angel Rivera Notararigo <
>> ntr...@gmail.com> wrote:
>>
>>> I tend to use errX (X is adapted according to context) for function 
>>> scoped errors, and err for block scoped errors
>>>
>>> func MyFunc() error {
   v, errDS := doSomething()
   ...
   errDA := doAnotherthing()
 }

>>>
>>> if err := doAnotherthing(); err != nil {
 return err
 }

>>>
>>> That way you don't shadow errors.
>>>
>>
>>
>> I can't +1 this enough.
>>
>> I've caught *so* many bugs from shadowed errors (and re-used error 
>> variables). I consider it a rather bad anti-pattern to have a single err 
>> variable 
>> that's reused throughout a scope.
>> If you have unique error variable names and you forget to do something 
>> with an error that you've assigned a name you automatically get unused 
>> variable compile-errors. (just this is enough to be worthwhile)
>>
>>
>> With that said, constraining the scope using the initializer statement on 
>> an if (or switch) statement suffices when you don't need any other return 
>> values, at which point I may use the err variable-name (although I often 
>> make those unique for clarity anyway).
>>
>>> -- 
>>> 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/CAF9DLCmR4ZdnVs4A28BSrPcbiHsQ_ufub5cSPjCt2SDy2dA1xA%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/9789bfb1-1944-4874-b7c6-785e16002been%40googlegroups.com.

Re: [go-nuts] Re: Do you have a minimal runnable go code that contain all key words in go?

[jake...@gmail.com]

Runs fine for me with one tiny change: https://go.dev/play/p/VRZKDFGzUcG

On Tuesday, December 7, 2021 at 7:21:31 PM UTC-5 Rob 'Commander' Pike wrote:

> Oh, it needs to be runnable. Never mind.
>
> -rob
>
> On Wed, Dec 8, 2021 at 11:19 AM Rob Pike  wrote:
> >
> > It's easy to fold a few things together: 
> https://go.dev/play/p/6lpZmGH9iJb
> >
> > Nice work though.
> >
> > On Wed, Dec 8, 2021 at 5:15 AM ben...@gmail.com  
> wrote:
> > >
> > > Heh, nice! I made it three bytes smaller by defining "const t = true" 
> (true was used in 2 places). https://go.dev/play/p/-3SvzKYjGSr ... I 
> can't think of any ways to reduce its (formatted) size further off the top 
> of my head, but I'm sure there's bound to be something.
> > >
> > > On Tuesday, December 7, 2021 at 2:47:41 AM UTC+13 
> axel.wa...@googlemail.com wrote:
> > >>
> > >> `new` is not a keyword, it is a predeclared identifier.
> > >> Here's a valid program that contains every keyword exactly once: 
> https://go.dev/play/p/YxfkoYDTN4h
> > >>
> > >> On Mon, Dec 6, 2021 at 2:34 PM Michael Ellis  
> wrote:
> > >>>
> > >>> Nice! Noticed it didn't have "new" so I changed the counter 
> initializer in main() from
> > >>>
> > >>> var c = counter
> > >>>
> > >>> to
> > >>>
> > >>> p := new(counter)
> > >>> var c = *p
> > >>>
> > >>> https://go.dev/play/p/2vw4w44qSWm
> > >>>
> > >>>
> > >>> On Sunday, December 5, 2021 at 4:10:54 PM UTC-5 ben...@gmail.com 
> wrote:
> > 
> >  Not strictly "minimal" -- it uses some keywords twice, and I'm sure 
> it's longer than it needs to be, but here you go: 
> https://go.dev/play/p/XPoqfI8RmyH
> > 
> >  On Monday, December 6, 2021 at 4:54:04 AM UTC+13 cuiw...@gmail.com 
> wrote:
> > >
> > > show me you code
> > >>>
> > >>> --
> > >>> 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/851b403a-dc73-487f-b10e-e1608cb8cda2n%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/378e15b4-11f5-4084-860f-250fe92bd33bn%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/efa3912b-2d9d-4178-966d-50794fc94cban%40googlegroups.com.

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

[jake...@gmail.com]

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/38cb92a8-38e4-4869-986d-3e0d939d8b47n%40googlegroups.com.

Re: [go-nuts] Strange cases of type definitions that use "[]", Go 1.17 and 1.18beta2

[jake...@gmail.com]

On Friday, February 11, 2022 at 10:02:42 AM UTC-5 kziem...@gmail.com wrote:

> I'm seriously lost here. Code below works in both Go 1.17 and Go 1.18beta2
>
> > package main
> >
> > import "fmt"
> >
> > type someInterface[3] interface {
> > SomeMethod()
> > }
> >
> > func main() {
> > var varSI someInterface
> >
> > fmt.Printf("varSI value: %v\n", varSI)
> > fmt.Printf("varSI type:  %T\n", varSI)
> > }
>
> and give in both cases result
> > varSI value: [  ]
> > varSI type:  main.someInterface
>
> I didn't find any way to assign some new value to "varSI", but this is 
> already disturbing to me.
>

FWIW, here is code that assigns to varSI in two ways:  
https://go.dev/play/p/ypj6rQbpBBl
Note that running this code in the playground will reformat ' type 
someInterface[3] interface' to the proper ' type someInterface 
[3]interface'. This is not a change in meaning, just a clarifying white 
space change made by `go fmt`. 

-- 
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/0e5d1a3f-c4fa-4cc3-b503-bfb885487dben%40googlegroups.com.

[go-nuts] Re: What goes wrong when embedding goroutines inside a for loop?

[jake...@gmail.com]

I think this explains it pretty well: Common Mistakes: Using goroutines on 
loop iterator variables 


On Thursday, February 17, 2022 at 11:45:39 AM UTC-5 yan.z...@gmail.com 
wrote:

> package main
> import "fmt"
>
> func main() {
> targetIndice := make([]int, 3)
> targetIndice[0] = 5
> targetIndice[2] = 4
> 
> for i,n := range targetIndice{
> fmt.Printf("%d : %d \n", i, n)
> }
> 
> c := make(chan int)
> for i, n:= range targetIndice{
> go func(){
> fmt.Printf("targetIndice[%d]=%d \n", i, n)
> c <- 1
> }()
> }
> 
> for i:=0; i<3; i++{
> <- c
> }
> 
> }
>
> -go run main.go-
> 0 : 5 
> 1 : 0 
> 2 : 4 
> targetIndice[2]=4 
> targetIndice[2]=4 
> targetIndice[2]=4 

-- 
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/4e22e6ae-2114-44d1-bca8-f649b0f84d8cn%40googlegroups.com.

Re: [go-nuts] all goroutines are asleep - deadlock!

[jake...@gmail.com]

The WaitGroup Documentation  says " A 
WaitGroup must not be copied after first use.". 

You are passing around and calling choppingActivity by value, so it is 
being copied after Add() is called, and again each call to choppingAction() 
and choppingSimulation(). 

If you run "go vet" on your code it will alert you to the problems. 

On Friday, March 25, 2022 at 10:27:02 AM UTC-4 sunto...@gmail.com wrote:

> *Re-using the old thread for a new problem that I'm getting:*
>
> fatal error: all goroutines are asleep - deadlock!
>
> I rewrote my 
> https://github.com/suntong/lang/blob/master/lang/Go/src/sys/butchers.go 
> files from procedure based to OO based, as
> https://github.com/suntong/lang/tree/master/lang/Go/src/sys/butchersOO
>
> The two programs behaves exactly the same, however my new "OO" approach 
> ended with 
>
> fatal error: all goroutines are asleep - deadlock!
> goroutine 1 [semacquire]:
>
> The only reason that I can think of is that,
>
> I changed my goroutine calling from function calling of
> `go choppingProblem(i, knifeLeft, knifeRight)`
> (
> https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchers.go#L79-L82
> )
>
> to method calling of
> `go chopping.choppingAction(i, knifeLeft, knifeRight, &st)`
> (
> https://github.com/suntong/lang/blob/9057e5718e00d396d0fe9a232820bdb79a31df72/lang/Go/src/sys/butchersOO/main.go#L129-L132
> )
>
> Might that be the reason? 
> How to fix the problem?
>
> 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/1e3d22ca-f4c0-4063-9fdf-6d6bdbcf3202n%40googlegroups.com.

Re: [go-nuts] Re: Windows Binaries and stdout

[jake...@gmail.com]

 This is really a Windows issue, and not related to Go. According to this 
very old post: 
https://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application
 
it is technically possible to do that, but the technique has flaws, foibles 
and limitations. 

This sounds like a 'rabbit hole' to me. I would suggest going back to what 
you actually want to accomplish, and thinking about alternative ways of 
achieving it.  

On Friday, April 29, 2022 at 4:46:19 AM UTC-4 stephen.t@gmail.com wrote:

> Hello Alex. Thanks for your response.
>
> On Fri, Apr 29, 2022 at 9:34 AM brainman  wrote:
>
>> Once windows executable is built, go has no control over how this program 
>> executes.
>>
>> When command line program is executed by clicking in explorer window 
>> Windows automatically starts a new console window and the console is used 
>> for stdout output (I did not check that). If command line program is 
>> started from existing cmd.exe console, new process just uses the same 
>> console.
>>
>> When you click on GUI executable in Windows explorer, no console windows 
>> is started (I did not check that). Same for GUI executable started from 
>> cmd.exe console - new GUI process is not attached to parent console (I did 
>> not check that).
>>
>
> Right. So I have a GUI executable that might be launched from a console 
> but it will not be "attached" to that parent console.
>
> Is there a way to attach the GUI executable to the parent console, perhaps 
> using a Windows system call?
>
>

-- 
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/a20dab65-79a4-4111-9cd4-44450109ba4cn%40googlegroups.com.

[go-nuts] Re: Add comparisons to all types

[jake...@gmail.com]

For a discussion of this issue as it relates to slices you might find this 
thread worth reading through: 
https://groups.google.com/g/golang-nuts/c/ajXzEM6lqJI/m/BmSu1m9PAgAJ

That was 2016, but not much has really changed since then on this issue. 

On Monday, May 2, 2022 at 10:43:53 PM UTC-4 will@gmail.com wrote:

> All types should have unrestricted comparisons (`==`, `!=`), but a few 
> pre-declared types don't. Adding them would bridge a semantic gap between 
> pre-declared and user-declared types, enabling all types to be used as map 
> keys, and otherwise make reasoning about them more consistent and intuitive.
>
> For the types that don't yet have unrestricted comparisons:
>
>- Functions: Compare the corresponding memory addresses. The time 
>complexity is constant.
>- Maps: Compare the corresponding `*runtime.hmap` (pointer) values. 
>The time complexity is constant.
>- Slices: Compare the corresponding `runtime.slice` (non-pointer 
>struct) values. The time complexity is constant.
>
> Examples:
>
> ```
> // Functions
>
> func F1() {}
> func F2() {}
>
> var _ = F1 == F1 // True
> var _ = F1 != F2 // True
>
> // Maps
>
> var M1 = map[int]int{}
> var M2 = map[int]int{}
>
> var _ = M1 == M1 // True
> var _ = M1 != M2 // True
>
> // Slices
>
> var S1 = make([]int, 2)
> var S2 = make([]int, 2)
>
> var _ = S1 == S1 // True
> var _ = S1 != S2 // True
>
> var _ = S1 == S1[:] // True because the lengths, capacities, and pointers 
> are equal
> var _ = S1 != S1[:1] // True because the lengths aren't equal
> var _ = S1[:1] != S1[:1:1] // True because the capacities aren't equal
> var _ = S1 != append(S1, 0)[:2:2] // True because the pointers aren't equal
> ```
>
> Function and map equality are consistent with channel equality, where 
> non-nil channels are equal if they were created by the same call to `make`. 
> Function values are equal if they were created by the same function literal 
> or declaration. Map values are equal if they were created by the same map 
> literal or the same call to `make`. Functions that are equal will always 
> produce the same outputs and side effects given the same inputs and 
> conditions; however, the reverse is not necessarily true. Maps that are 
> equal will always contain the same keys and values; however, the reverse is 
> not necessarily true.
>
> Slice equality is consistent with map equality. Slice values are equal if 
> they have the same array pointer, length, and capacity. Slices that are 
> equal will always have equal corresponding elements. However, like maps, 
> slices that have equal corresponding elements are not necessarily equal.
>
> This approach to comparisons for functions, maps, and slices makes all 
> values of those types immutable, and therefore usable as map keys.
>
> This would obviate the `comparable` constraint, since all type arguments 
> would now satisfy it. In my opinion, this would make the language simpler 
> and more consistent. Type variables could be used with comparison 
> operations without needing to be constrained by `comparable`.
>
> If you think slice equality should incorporate element equality, here's an 
> example for you:
>
> ```
> type Slice1000[T any] struct {
> xs *[1000]T
> len, cap int
> }
>
> func (s Slice1000[T]) Get(i int) T {
> // ...
> return s.xs[i]
> }
>
> func (s Slice1000[T]) Set(i int, x T) {
> // ...
> s.xs[i] = x
> }
>
> var xs1, xs2 [1000]int
>
> var a = Slice1000[int]{&xs1, 1000, 1000}
> var b = Slice1000[int]{&xs2, 1000, 1000}
> var c = a == b
> ```
>
> Do you expect `c` to be true? If not (it's false, by the way), then why 
> would you expect `make([]int, 2) == make([]int, 2)` to be true?
>
> Any thoughts?
>

-- 
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/44f47793-4b8d-4cd4-bc82-a045937e2227n%40googlegroups.com.

[go-nuts] Re: Add comparisons to all types

[jake...@gmail.com]

On Wednesday, May 4, 2022 at 12:34:10 PM UTC-4 jake...@gmail.com wrote:

> For a discussion of this issue as it relates to slices you might find this 
> thread worth reading through: 
> https://groups.google.com/g/golang-nuts/c/ajXzEM6lqJI/m/BmSu1m9PAgAJ
>
> That was 2016, but not much has really changed since then on this issue. 
>
 
Oops, that links to the middle of the thread. This is slightly better:  
https://groups.google.com/g/golang-nuts/c/ajXzEM6lqJI

-- 
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/f709bc52-46ed-4578-8b4c-ae8f63ec1f5cn%40googlegroups.com.

[go-nuts] Re: GO program's memory footprint is confusing

[jake...@gmail.com]

Since no one has responded with concrete ideas, I'll throw out two 
suggestions. They may seem obvious.

 First have you tries the latest version of Go? and do you get the same 
results?

 Second have you run the experiment with a small binaries not from Go? I 
would suggest something that does allocate some real memory, *not *a "hello 
world" C program or something.
On Thursday, May 5, 2022 at 7:21:39 AM UTC-4 garenchan wrote:

>
> Both hosts have 8 cores and 16GB RAM.
> 在2022年4月30日星期六 UTC+8 00:19:44 写道：
>
>> *What version of Go are you using (go version)?*
>>
>> $ go version
>> go version go1.17.6 linux/amd64
>>
>> *Does this issue reproduce with the latest release?*
>>
>> uncertain
>>
>> *What operating system and processor architecture are you using (go env)?*
>>
>> $ go env
>> GO111MODULE="on"
>> GOARCH="amd64"
>> GOBIN=""
>> GOCACHE="/root/.cache/go-build"
>> GOENV="/root/.config/go/env"
>> GOEXE=""
>> GOEXPERIMENT=""
>> GOFLAGS=""
>> GOHOSTARCH="amd64"
>> GOHOSTOS="linux"
>> GOINSECURE=""
>> GOMODCACHE="/root/go/pkg/mod"
>> GONOPROXY=""
>> GONOSUMDB=""
>> GOOS="linux"
>> GOPATH="/root/go"
>> GOPRIVATE=""
>> GOPROXY=""
>> GOROOT="/home/go"
>> GOSUMDB="off"
>> GOTMPDIR=""
>> GOTOOLDIR="/home/go/pkg/tool/linux_amd64"
>> GOVCS=""
>> GOVERSION="go1.17.6"
>> GCCGO="gccgo"
>> AR="ar"
>> CC="gcc"
>> CXX="g++"
>> CGO_ENABLED="1"
>> GOMOD="/home/demo/go.mod"
>> CGO_CFLAGS="-g -O2"
>> CGO_CPPFLAGS=""
>> CGO_CXXFLAGS="-g -O2"
>> CGO_FFLAGS="-g -O2"
>> CGO_LDFLAGS="-g -O2"
>> PKG_CONFIG="pkg-config"
>> GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
>> -fdebug-prefix-map=/tmp/go-build4023324410=/tmp/go-build 
>> -gno-record-gcc-switches"
>>
>> *What did you do?*
>>
>> I encountered a memory problem with the GO program, see here for details.(
>> https://stackoverflow.com/questions/71994609/memory-footprint-of-the-same-program-varies-greatly-in-two-similar-environments
>> )
>>
>> In order to simplify the analysis, I wrote a simple program to test.
>>
>> ```go
>> package main
>>
>> import (
>> "time"
>> )
>>
>> func main() {
>> time.Sleep(60*time.Second)
>> }
>> ```
>>
>>
>>- I compiled it into binary file on a linux host `host1` with kernel 
>>4.18. Then I run it on `host1` and the process takes up close to 5MB RSS.
>>- I then copy the binary file to another host `host2` with kernel 
>>4.18. I also ran it on `host2`, but this time the process took up less 
>> than 
>>1MB RSS.
>>- I repeated the test many times and observed the same thing.
>>
>>
>> ```
>> $ uname -a
>> Linux host1 4.18.0 #1 SMP Wed Nov 10 20:46:19 CST 2021 x86_64 x86_64 
>> x86_64 GNU/Linux
>>
>> $ uname -a
>> Linux host2 4.18.0 #1 SMP Fri May 8 10:59:10 UTC 2021 x86_64 x86_64 
>> x86_64 GNU/Linux
>> ```
>>
>> Why is memory footprint of the same program in similar environments so 
>> different? What factors might be contributing to this problem?
>>
>> *What did you expect to see?*
>>
>> I would expect to see the memory footprint of the same program in similar 
>> environments be close. I look forward to your answers. Thank you very much.
>>
>

-- 
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/0ca64767-8890-4fbd-a827-373606c37dd5n%40googlegroups.com.

[go-nuts] Re: How to call function from struct in slice?

[jake...@gmail.com]

I find your example code confusing, and it *appears* to have multiple 
syntax errors, which make it impossible to compile. If you could post a 
complete "working" example to the playground you would probably get a 
better response. 

On Thursday, June 2, 2022 at 8:17:04 AM UTC-4 Jay wrote:

>
>
> In a code example, I’m confuse if it’s possible to call ModuleName() each 
> package API after execute CompileModules()?
>
>
> app.go
>
>
> func CompileModules() []interface{
>
> return []interface{
>
> Example1.AddModule(),
>
> Example2.AddModule(),
>
> Example3.AddModule(),
>
> }
>
> }
>
>
>
>
> Init.go in Hello1 folder:
>
> package Example1
>
>
> type AddModule struct {}
>
>
> func (p *AddModule) ModuleName() string {
>
> return “Hello 1”
>
> }
>

-- 
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/2b443efe-0ebf-4a75-8dc2-adc6d3008758n%40googlegroups.com.

[go-nuts] Re: How to call function from struct in slice?

[jake...@gmail.com]

Your playground example was still not runnable.
I have fixed it so it runs: https://go.dev/play/p/I57OftEerLY
Now that we have a working example, what precisely is the problem you are 
having?
On Saturday, June 4, 2022 at 2:56:43 PM UTC-4 Little Ant wrote:

> Thank you Jake, 
>
> I have not have a complete working solution, but I have included comments 
> to understand the feature I'm trying to build to add or remove my custom 
> modules similar to written CMS that add and remove modules/plugins. Unsure 
> if I should go by "receiver" way or method way.
>
> https://go.dev/play/p/38sL3P-BSDr
>
>
>
> On Sunday, June 5, 2022 at 12:04:54 AM UTC+8 jake...@gmail.com wrote:
>
>> I find your example code confusing, and it *appears* to have multiple 
>> syntax errors, which make it impossible to compile. If you could post a 
>> complete "working" example to the playground you would probably get a 
>> better response. 
>>
>> On Thursday, June 2, 2022 at 8:17:04 AM UTC-4 Jay wrote:
>>
>>>
>>>
>>> In a code example, I’m confuse if it’s possible to call ModuleName() 
>>> each package API after execute CompileModules()?
>>>
>>>
>>> app.go
>>>
>>>
>>> func CompileModules() []interface{
>>>
>>> return []interface{
>>>
>>> Example1.AddModule(),
>>>
>>> Example2.AddModule(),
>>>
>>> Example3.AddModule(),
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>>
>>> Init.go in Hello1 folder:
>>>
>>> package Example1
>>>
>>>
>>> type AddModule struct {}
>>>
>>>
>>> func (p *AddModule) ModuleName() string {
>>>
>>> return “Hello 1”
>>>
>>> }
>>>
>>

-- 
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/c45e5942-1b52-4ef7-a1e2-2f079fc41f01n%40googlegroups.com.

[go-nuts] Re: How to use thrifter.ToJSON() function

[jake...@gmail.com]

>From your first question, it appears that you have never used Go before. I 
would start with the intro tutorial: A Tour of Go . 
Other resources and tutorials on the official documentation page 
 might also be helpful.

I would also note that the thrift-iterator source 
 is not being actively maintained, 
as the last change was 4 years ago. It also does not appear to have a 
go.mod file, which is now more-or less required. So you may need to fork it 
and add one. 

On Wednesday, June 8, 2022 at 2:35:14 PM UTC-4 1vaishna...@gmail.com wrote:

> Hi all!
>
> I'm working on a project in golang, where I have to convert a thrift 
> string into json. I came across thrifter package. thrift-iterator 
> .   
> Please help me write 
> 1) How to import?
> 2) Import external dependencies using bazel
> 3) Also, does thrifter.ToJSON recursively includes other thrift files from 
> the given thrift file.
> like:
> *xyz.thrift file:*
> namespace
> include"abc.thrift"
> -
> -
>
> Will abc will also be included when converting xyz.thrift file into json, 
> while using thrift.ToJSON.
>
> If there exist some another method to convert thrift into json in golang 
> please let me know.
> Please help. Thanks a lot
>

-- 
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/9f915102-56cb-4943-9f2c-ff8af7e8df24n%40googlegroups.com.

Re: [go-nuts] Elementary Question About Calling Functions in Different Packages

[jake...@gmail.com]

>
> So, I'll probably have to keep using multiple packages if I can somehow 
> figure out how to solve
> the package import cycle problem.
>

The most common solution is to factor out the aspects which cause the cycle 
> into a third package that one or both of the current packages imports. In 
> my four decades of programming I've only seen one import cycle (in Python) 
> that was hard to remove. My team eventually used the "Python lazy import" 
> hack. Refactoring the code to eliminate the import cycle, and therefore the 
> hack to handle it, was high on my team's priority list when I left the 
> project.
>

In Go interfaces can also sometimes be helpful in eliminating import cycles

-- 
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/363e950d-df84-41a0-afcf-78c1143631c3n%40googlegroups.com.

Re: [go-nuts] About Go 1.19 memory model clarificaitons on atomic operations.

[jake...@gmail.com]

On Monday, August 15, 2022 at 5:20:58 AM UTC-4 ma...@changkun.de wrote:

> > Any other reading, to me, is trying to find an ambiguity for the sole 
> sake of finding an ambiguity. 
>
> A reader does not have to be motivated to find ambiguity. If the 
> sentence can be interpreted with different meanings, other readers may 
> perceive it differently. To me, the first read of this sentence is 
> perceived to be ambiguous regarding a single location or multiple 
> locations. The posted example discusses a and b as two memory 
> locations. 
>
> Atomic operations on a and b are two different statements. It remains 
> unclear where exactly is the sentence that tries to say this: atomic 
> operations on different memory locations obey the program statements 
> order within a goroutine. 
>

Doesn't the Section on Atomics  statement 
say just that:

The APIs in the sync/atomic  package are 
collectively “atomic operations” that can be used to synchronize the 
execution of different goroutines. If the effect of an atomic operation *A* 
is observed by atomic operation *B*, then *A* is synchronized before *B*. 
All the atomic operations executed in a program behave as though executed 
in some sequentially consistent order.  

Is your confusion about the term "observed"?
 

-- 
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/3a266d04-db5c-4e16-bf1e-3ea6c7a98168n%40googlegroups.com.

[go-nuts] Re: Excelize

[jake...@gmail.com]

I am not familiar with that package. However, if you are referring to 
github.com/360entsecgroup-skylar/excelize, you can search the issues there 
on github, and there is some discussion of "secondary axis", which may be 
what you are referring to. Spoiler, it looks like it is not implemented ... 
but do check for yourself, because maybe it is not the same as what you are 
asking about. 

Good luck

On Tuesday, August 16, 2022 at 5:47:32 PM UTC-4 djan...@gmail.com wrote:

> Hi,
> I am using Golang Excelize to generate charts. I would like to use the 
> secondary axis for series.
> Does anyone know where there is an example?
>
> Thank you
> -- 
> DanJ
>

-- 
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/f3613e76-4182-4b94-a12b-89cd7665b6d5n%40googlegroups.com.

[go-nuts] Re: the difference between type and type address in struct

[jake...@gmail.com]

The terminology we would generally use is '*dog' is a pointer, not a "type 
address".

The difference really has nothing to do with structs, but is the difference 
between a value and a pointer to a value. If you understand pointers in 
general, then this more complicated case will make sense. I suggest 
searching "pointers in go explained", which will give you a number of 
tutorials that explain pointers. 

In this case, the biggest difference is that each instance of B will always 
contain its own 'dog' value, but instances of A may share a 'dog' value, if 
d points to the same 'dog' value. Seehttps://go.dev/play/p/NlSsMc8b7To for 
a demonstration. 

On Sunday, August 28, 2022 at 6:56:30 AM UTC-4 mandel...@gmail.com wrote:

> the difference between type  and  type address in struct
> type dog struct {
>  age int 
>  name string
> } 
> type A struct {
>  d *dog
> }
> type B struct {
>  d dog
> }
> the difference between struct A and struct B.
>

-- 
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/2ea28cbb-7a3c-457d-a461-0f52a1a26866n%40googlegroups.com.

[go-nuts] Re: maps.Keys() does not work when keys are of type language.Tag

[jake...@gmail.com]

It appears to be because, deep down, the language.Tag struct contains an 
interface. While interfaces are "comparable", in that you can use == & !=, 
apparently they do not implement the  'comparable 
' constraint. 

I'm not sure why this decision was made, though I can guess. There is 
probably discussion about it somewhere. It does seem to me that this should 
be documented the  'comparable' constraint documentation 
. It also makes me wonder if there 
are other cases where '==' compiles, but the types are not 'comparable'.

On Thursday, October 6, 2022 at 7:29:46 AM UTC-4 joche...@gmail.com wrote:

> Hello,
>
> Using "golang.org/x/text/language" I have a map of 
> type map[language.Tag]int.  I would like to get the keys present in my 
> map.  Why does the following command not work?
>
> import "golang.org/x/exp/maps"
> ...
> var x map[language.Tag]int
> ...
> fmt.Println(maps.Keys(x))
>
> The error message is "Tag does not implement comparable".  Code on the 
> playground: https://go.dev/play/p/dsyEt0ClDBH .
>
> The following function does work as expected, so this is easy to work 
> around:
>
> func myKeys(m map[language.Tag]int) []language.Tag {
> var res []language.Tag
> for key := range m {
> res = append(res, key)
> }
> return res
> }
>
> But I wonder now whether it is unwise to use language.Tag for the keys in 
> a map, and why maps.Keys() requires the keys to implement "comparable" in 
> addition to the constraint "M ~map[K]V".
>
> Many thanks,
> Jochen
>
>
>
>
>

-- 
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/7f577a92-b45c-47ca-93e1-b8684a6be0fen%40googlegroups.com.