[go-nuts] Re: How to have panic messages show in a PowerShell console

[jake...@gmail.com]

FWIW,  in a very simple test on Windows 10 in a powershell console, running 
a go executable built with go1.19 prints the panic just like in a regular 
cmd console.

On Wednesday, February 28, 2024 at 3:20:55 PM UTC-5 Thom BENTLEY wrote:

> Hi All, 
>
> OS: Windows 10
> GoLang: go1.6.3 windows/386
>
> I am trying to have a go executable run and show the panics it causes in 
> the PowerShell console.  
>
> I think I can use GODEBUG, but all the examples I've seen so far are for 
> Linux.
> I've set that variable to paniclog=1, but nothing changed.
>
> If I run go env, I don't see GODEBUG listed.
> Thanks in advance.
>
>
> --
> The information in this email and any attachments are intended solely for 
> the recipient(s) to whom it is addressed, and may be confidential and/or 
> privileged. Any unauthorized distribution or copying of this transmittal or 
> its attachments is prohibited. If you are not a named recipient or have 
> received this email in error: (i) you should not read, disclose, or copy 
> it, (ii) please notify the sender of your receipt by reply email and delete 
> this email and all attachments.
>

-- 
You received this message because you are subscribed to the Google 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/53c4fa69-32cd-4111-a0d5-d545d9851bf8n%40googlegroups.com.

Re: [go-nuts] Equality of interface of an empty struct - why?

[jake...@gmail.com]

What is really fantastical is that a==b prints false, even though the 
pointers are actually the same. I am guessing some sort of optimization 
effect is at play here. 

https://go.dev/play/p/Dsqeh_aAXKT

type Foo struct {
}

func main() {

a := {}
b := {}
fmt.Printf("%t\n", *a == *b)
fmt.Printf("%t\n", a == b)
q := uintptr(unsafe.Pointer(a))
r := uintptr(unsafe.Pointer(b))
//fmt.Printf("%p %p\n", a, b)
fmt.Printf("%t\n", q == r)
fmt.Printf("%x %x\n", q, r)
} 

prints:

true 
false 
true 
c000104ee0 c000104ee0

wild! (or am I missing something?)
On Thursday, February 22, 2024 at 1:07:08 PM UTC-5 Axel Wagner wrote:

> On Thu, Feb 22, 2024 at 6:44 PM burak serdar  wrote:
>
>> Maybe the spec should be clarified to say "for a compilation of a
>> program, two pointers to zero-size variables may or may not be equal",
>> because otherwise it implies that if you have
>>
>> x:= a==b
>> y:= a==b
>>
>> x may or may not be true.
>
>
> Well, given that the spec is *not* saying what you say it maybe should - 
> it seems we are in agreement. It is indeed correct for `x` to may or not be 
> equal to `y` here, with the spec as it is right now.
>  
>
>> If a==b, then that should hold for every
>> execution of that program, and throughout the program.
>>
>>
>> >
>> >>
>> >> That is, if a==b, then
>> >> interface{}(a)==interface{}(b), and vice versa. But what we have here
>> >> is a!=b but interface{}(a)==interface{}(b)
>> >>
>> >> On Thu, Feb 22, 2024 at 9:50 AM Axel Wagner
>> >>  wrote:
>> >> >
>> >> > Hm actually, the spec allows for this, technically speaking: 
>> https://go.dev/ref/spec#Comparison_operators
>> >> >
>> >> > > Pointers to distinct zero-size variables may or may not be equal.
>> >> >
>> >> > Arguably, this genuinely would allow comparison of pointers to 
>> zero-sized variables to have any behavior whatsoever (including being 
>> random). But it certainly is confusing.
>> >> >
>> >> >
>> >> > On Thu, Feb 22, 2024 at 5:46 PM Axel Wagner <
>> axel.wa...@googlemail.com> wrote:
>> >> >>
>> >> >> I see. Sorry, I was jumping to conclusions and didn't quite get 
>> what you mean. That is my fault.
>> >> >>
>> >> >> I agree that this looks confusing and is arguably a bug. I filed 
>> https://github.com/golang/go/issues/65878, thanks for pointing it out.
>> >> >>
>> >> >> On Thu, Feb 22, 2024 at 5:20 PM burak serdar  
>> wrote:
>> >> >>>
>> >> >>> Creating  an interface is not creating a pointer to a zero sized 
>> variable.
>> >> >>>
>> >> >>> a==b  prints false. That means, a and b point to different 
>> locations
>> >> >>> Bar(a)==Bar(b) prints true. If a!=b, then Bar(a) must be different 
>> from Bar(b)
>> >> >>>
>> >> >>> On Thu, Feb 22, 2024 at 9:15 AM Axel Wagner
>> >> >>>  wrote:
>> >> >>> >
>> >> >>> > If you expect that, you are misreading the spec. There is no 
>> guarantee of any behavior here. An implementation is allowed to flip a 
>> coin, every time you create a pointer to a zero-sized variable, and either 
>> return a unique pointer or a singleton. I think you may assume that  == 
>> , always. But apart from that, who knows.
>> >> >>> >
>> >> >>> > Zero-sized variables *may* have the same address. They don't 
>> *have* to.
>> >> >>> >
>> >> >>> > On Thu, Feb 22, 2024 at 5:12 PM burak serdar <
>> bse...@computer.org> wrote:
>> >> >>> >>
>> >> >>> >> On Thu, Feb 22, 2024 at 9:00 AM Axel Wagner
>> >> >>> >>  wrote:
>> >> >>> >> >
>> >> >>> >> > Note that in the Spec section I quoted above it says "Two 
>> distinct zero-size variables may have the same address in memory" (emphasis 
>> mine).
>> >> >>> >> > There is no guarantee, that all zero-sized values have the 
>> same address (otherwise, you'd get into inefficiencies when taking the 
>> address of a zero-sized field in a larger struct, or when converting a 
>> zero-capacity slice into an array-pointer). But it is allowed.
>> >> >>> >> > If you require two pointers returned from different code 
>> paths to be different, for correctness, then you have to make them point at 
>> something that has non-zero size. Otherwise, all potential combinations are 
>> valid according to the spec.
>> >> >>> >>
>> >> >>> >> Yes. But in that case, you'd expect either  a==b and 
>> Bar(a)==Bar(b) to
>> >> >>> >> be both true, or both false. In this case, one is true and the 
>> other
>> >> >>> >> is not.
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> >
>> >> >>> >> > On Thu, Feb 22, 2024 at 4:53 PM burak serdar <
>> bse...@computer.org> wrote:
>> >> >>> >> >>
>> >> >>> >> >> The compiler can allocate the same address for empty 
>> structs, so I
>> >> >>> >> >> actually expected a==b to be true, not false. However, 
>> there's
>> >> >>> >> >> something more interesting going on here because:
>> >> >>> >> >>
>> >> >>> >> >> a := {}
>> >> >>> >> >> b := {}
>> >> >>> >> >> fmt.Printf("%t\n", *a == *b)
>> >> >>> >> >> fmt.Printf("%t\n", a == b)
>> >> >>> >> >> fmt.Printf("%p %p\n", a, b)
>> >> >>> >> >> x := Bar(a)
>> >> >>> >> >> y := Bar(b)
>> >> >>> >> >> fmt.Printf("%t\n", 

[go-nuts] Re: GO language best practice document

[jake...@gmail.com]

In addition to the style guide, I have found 
https://github.com/golang/go/wiki/CodeReviewComments to have some 
interesting insights.

On Friday, September 8, 2023 at 9:05:12 AM UTC-4 Alexandre Roy wrote:

> Hi,
>
> I want to start a new web application using GO with AWS Lambda, but first 
> I want to learn the GO language. I mostly have C / Python experience. 
>
> I started reading https://go.dev/doc/effective_go, but as mentioned in 
> the following issue https://github.com/golang/go/issues/28782, this 
> documentation is deprecated with new best practice.
>
> Since the issue is still open and no new document is available, what do 
> you recommend to learn GO the right way (best practice) in 2023?
>
> Thanks for your help and your time,
>
> Alexandre
>

-- 
You received this message because you are subscribed to the Google 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/86aa6041-abd8-40bb-bb64-dd559abde79cn%40googlegroups.com.

[go-nuts] Re: slog's use of runtime.Callers() with a skip

[jake...@gmail.com]

As far as I can tell, skip works even in the face of inlined functions, at 
least when used with runtime.CallersFrames(). It would be surprising  to me 
if it did not. Do you have any evidence to the contrary?

On Friday, August 4, 2023 at 9:51:34 AM UTC-4 sh...@tigera.io wrote:

> I was looking at replacing logrus with the new slog library in our 
> project.  I noticed that it uses runtime.Callers() with a fixed skip 
>  
> to collect the PC of the calling code, presumably to make it possible for 
> the handler to emit line number and filename.
>
> Question is: is that sound in the face of inlining functions?  I think if 
> the Info method gets inlined then the skip might be too large, for example.
>
> I remember having to change similar code in our project to use 
> runtime.CallersFrames in order to deal with inlining. Quite possible 
> there's a way to deal with an inlined PC that I wasn't aware of, but it 
> seemed wrong to me.
>
> -Shaun
>

-- 
You received this message because you are subscribed to the Google 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/58b0c0ef-c8be-484f-8d90-5c7ca15dcf32n%40googlegroups.com.

[go-nuts] Re: Where are closure storing the captured variables ?

[jake...@gmail.com]

In addition to Axel's useful info, whenever you are interested in what 
escapes to the 'heap', it  can be helpful to build with escape analyses 
output. Try using "go build  -gcflags=-m". 

On Wednesday, July 5, 2023 at 8:35:52 PM UTC-4 chris...@meessen.net wrote:

> Hello,
>
> Closure need space to store the captured variables. According to 
> runtime.MemStats, it is not on the heap. Where are these variable stored ? 
> On the stack ?
>

-- 
You received this message because you are subscribed to the Google 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/9ed36da2-c466-420a-8724-fdd9f14455fan%40googlegroups.com.

[go-nuts] Re: 'go run hello.go' taking ~30 seconds on windows

[jake...@gmail.com]

This may be related. I have always had a significant delay when building Go 
programs on Windows. It mostly happens the first time I build, if I have 
not built recently. A normal build of a simple program is about 3 seconds 
of wall clock time, whereas it can take over 20 seconds when it is being 
slow. Using the Windows tool Process Monitor, I was able to determine that 
my problem is that a huge number of go standard library files are being 
read, in their entirety on every build. I thought there was package caching 
of some sort to avoid this, but apparently not. So about 2,000 standard 
library files are being read in to build a tiny program. When it is being 
'slow' these take around 10-40 milliseconds each. Once things are warmed 
up, they typically take 0.01 to 0.03 milliseconds each. That seems to 
account for much of the initial slow build. I am assuming the difference is 
whether the files are cached in memory by Windows?

I am currently running go 1.19, but have had the same issue for years. 
Using Windows 10, with anti-virus shut off for the source and build 
directories.

By the way, the Process Monitor tool from Microsoft can be useful in 
situations like these, as it can give a good indication of how long every 
operation is taking. 
On Wednesday, December 14, 2022 at 12:57:40 PM UTC-5 Declan Finn wrote:

> Hi,
>
> Platform: Windows 10
> Go Version: 1.19.4
>
> Compile and run of the most basic helloworld program is extremely slow on 
> my windows machine, taking roughly 30 seconds every time.
> Whereas the exact same program, using the same go version, compiles and 
> runs in under 1 second on my Ubuntu machine.
> Why is it so slow on windows?
> I asked a collogue to do the same test on his windows machine and he sees 
> the same slowness.
> Any help would be greatly appreciated.
>
>
>

-- 
You received this message because you are subscribed to the Google 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/43a09191-94e8-4722-a2ea-c072ccb8654en%40googlegroups.com.

[go-nuts] Re: Pointer constraint to generics

[jake...@gmail.com]

What About:

func PointerOrError[T *Q, Q any](s C.StatusOr ) (t T, err error) 

Seems to compile: https://go.dev/play/p/n4I-XkONj-O?v=gotip

On Saturday, April 15, 2023 at 6:28:39 AM UTC-4 Jan wrote:

> hi,
>
> This is a variation for a previous topic 
> , 
> but since there isn't a clear solution, I thought I would ask if anyone can 
> think of a work around.
>
> I've been interacting a lot with C++ libraries from Go, and one of the 
> commonly returned types is an abls::StatusOr 
> , for which I created a simple 
> C wrapper that casts the error and value to a `char *` and `void *` 
> respectively (dropping the type information in between C++ and Go).
>
> In Go I want to return the type information, so I defined a small generic 
> function:
>
> // PointerOrError converts a StatusOr structure to either a pointer to T 
> with the data
> // or the Status converted to an error message and then freed.
> func PointerOrError[T any](s C.StatusOr) (*T, error) {
> ptr, err := UnsafePointerOrError(s) // returns unsafe.Pointer, error
> if err != nil {
> return nil, err
> }
> return (*T)(ptr), nil
> }
>
> Now this doesn't work for my forward declared C++ types (most of them are 
> just aliases to C++ objects) -- Go complaints with: `cannot use 
> incomplete (or unallocatable) type as a type argument`, because `T` is 
> incomplete indeed.
>
> But ... I will never instantiate `T`, I only care about `*T`, which is not 
> incomplete.
>
> But there isn't a way to say a generics attribute is a pointer. So if I 
> use the following:
>
> func PointerOrError2[T any](s C.StatusOr) (t T, err error) {
> var ptr unsafe.Pointer
> ptr, err = UnsafePointerOrError(s) // <-- unsafe.Pointer, error
> if err != nil {
> return
> }
> t = (T)(ptr)
> return
> }
>
> And instantiate it with a `PointerOrError2[*MyType](statusOr)` for 
> instance, I get, as expected:
>
> cannot convert ptr (variable of type unsafe.Pointer) to type T
>
> Any suggestions to make this work ? 
>
> I could probably craft something using the `reflect` package, but I was 
> hoping for a smart (and likely faster?) generics solution.
>
> cheers
> Jan
>
>
>
>
>
>
>

-- 
You received this message because you are subscribed to the Google 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/b9e377dd-4ef8-4cdf-8c36-80cb086910b1n%40googlegroups.com.

[go-nuts] Re: Ask about Golang Behavior

[jake...@gmail.com]

You have:
fmt.Println("AFTER:", newMessage.Biawaks == nil, cap(message.Biawaks)) 
Did you mean:
fmt.Println("AFTER:", newMessage.Biawaks == nil, cap( newMessage.Biawaks))

If so, then 
On Monday, March 20, 2023 at 11:44:54 AM UTC-4 febriananda pramudita wrote:

> I was playing with protobuf marshaller recently and found this behavior
>
> https://gist.github.com/FwP-pintu/448f8ecddf27987a7e5b8a103eda12cb
>
> Is behavior: "nil slice with more than 0 capacity" is intended? 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/9c65b63e-1678-4646-a2ad-233367cdbe85n%40googlegroups.com.

[go-nuts] Re: catching an internal/poll error?

[jake...@gmail.com]

You might want to dig a bit more. The error that generated that string 
would not be an ErrFileClosing. It appears that it originated with an 
ErrFileClosing, but by the time it gets to you it has been wrapped more 
than once as it percolated up the layers of code. 

On Sunday, February 19, 2023 at 2:10:11 PM UTC-5 Mike Nolta wrote:

> Hi,
>
> My code recently died with this error string: "write |1: copy_file_range: 
> use of closed file". 
>
> I'd like to catch it, since i'm already catching file closed errors 
> (fs.ErrClosed). But the error appears to be ErrFileClosing from the 
> internal/poll package [1], and i'm not allowed to import it.
>
> Go version is 1.18.10, OS is ubuntu-latest from github actions.
>
> Thanks,
>
> -Mike
>
> [1]: 
> https://cs.opensource.google/go/go/+/refs/tags/go1.20.1:src/internal/poll/fd.go;l=35
>
>

-- 
You received this message because you are subscribed to the Google 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/72e02209-0e50-486f-b418-353f525b5f73n%40googlegroups.com.

[go-nuts] Re: memory issues

[jake...@gmail.com]

What Marcello said! 

But also, the message mentions bad use of Unsafe.Pointer. You might want to 
look at uses in your app, and even third party libraries. See the 
documentation: https://pkg.go.dev/unsafe#Pointer - The rules must be 
followed to the letter! 

Are you using cgo? It also has very specific rules. 
On Thursday, February 9, 2023 at 3:02:08 AM UTC-5 Marcello H wrote:

> I would trim down the problem, by making a very small program that gets 
> the XML file from a local disk and then just do the XSLT on it.
> That would give you less environment to oversee and debug.
> Perhaps then, make the xml as small as possible.
> Also mention which libs you use or make a playground version of the 
> problem, so people might be able to understand more about the problem.
>
> Op donderdag 9 februari 2023 om 00:03:03 UTC+1 schreef James Dornan:
>
>> I have a go web service that acts as a proxy that gets XML documents from 
>> a remote system and processes them through XSLT, returning the result, if 
>> any. I have tried a number of options over the last few days and cannot 
>> seem to nail down the cause.
>>
>> Does anyone know how to address this or debug the issue? Thanks.
>>
>> Version 1.20 (on Alpine Linux 3.17)
>>
>> Build statement
>>
>> go build \
>> -tags musl \
>>  -ldflags '-extldflags "-static -lz -llzma -lgcrypt -lgpg-error"' \
>> -gcflags=all="-wb=false -d=checkptr" \
>>   -a  main.go
>>
>> runtime: marked free object in span 0x7f58c3422308, elemsize=96 
>> freeindex=3 (bad use of unsafe.Pointer? try -d=checkptr)
>> 0xc000398000 alloc marked
>> 0xc000398060 alloc marked
>> 0xc0003980c0 alloc marked
>> 0xc000398120 free  unmarked
>> 0xc000398180 free  unmarked
>> 0xc0003981e0 free  unmarked
>> 0xc000398240 alloc marked
>> 0xc0003982a0 alloc marked
>> 0xc000398300 free  unmarked
>> 0xc000398360 alloc marked
>> 0xc0003983c0 alloc marked
>> 0xc000398420 alloc marked
>> 0xc000398480 free  unmarked
>> 0xc0003984e0 free  unmarked
>> 0xc000398540 free  unmarked
>> 0xc0003985a0 free  unmarked
>> 0xc000398600 free  unmarked
>> 0xc000398660 free  unmarked
>> 0xc0003986c0 free  unmarked
>> 0xc000398720 free  unmarked
>> 0xc000398780 free  unmarked
>> 0xc0003987e0 alloc marked
>> 0xc000398840 alloc marked
>> 0xc0003988a0 free  unmarked
>> 0xc000398900 free  unmarked
>> 0xc000398960 free  unmarked
>> 0xc0003989c0 free  unmarked
>> 0xc000398a20 free  unmarked
>> 0xc000398a80 free  unmarked
>> 0xc000398ae0 free  unmarked
>> 0xc000398b40 free  unmarked
>> 0xc000398ba0 free  unmarked
>> 0xc000398c00 free  unmarked
>> 0xc000398c60 free  unmarked
>> 0xc000398cc0 free  unmarked
>> 0xc000398d20 free  unmarked
>> 0xc000398d80 free  unmarked
>> 0xc000398de0 free  unmarked
>> 0xc000398e40 free  unmarked
>> 0xc000398ea0 free  unmarked
>> 0xc000398f00 alloc marked
>> 0xc000398f60 free  unmarked
>> 0xc000398fc0 alloc marked
>> 0xc000399020 alloc marked
>> 0xc000399080 free  unmarked
>> 0xc0003990e0 free  unmarked
>> 0xc000399140 alloc marked
>> 0xc0003991a0 alloc marked
>> 0xc000399200 alloc marked
>> 0xc000399260 free  unmarked
>> 0xc0003992c0 free  unmarked
>> 0xc000399320 free  unmarked
>> 0xc000399380 free  unmarked
>> 0xc0003993e0 free  unmarked
>> 0xc000399440 free  unmarked
>> 0xc0003994a0 free  unmarked
>> 0xc000399500 free  unmarked
>> 0xc000399560 free  unmarked
>> 0xc0003995c0 free  unmarked
>> 0xc000399620 alloc marked
>> 0xc000399680 free  unmarked
>> 0xc0003996e0 free  marked   zombie
>> 0x00c0003996e0:  0x00c000104b60  0x
>> 0x00c0003996f0:  0x  0x
>> 0x00c000399700:  0x  0x
>> 0x00c000399710:  0x0100  0x
>> 0x00c000399720:  0x  0x
>> 0x00c000399730:  0x  0x
>> 0xc000399740 free  unmarked
>> 0xc0003997a0 alloc marked
>> 0xc000399800 alloc marked
>> 0xc000399860 free  unmarked
>> 0xc0003998c0 free  unmarked
>> 0xc000399920 free  unmarked
>> 0xc000399980 free  unmarked
>> 0xc0003999e0 free  unmarked
>> 0xc000399a40 free  unmarked
>> 0xc000399aa0 free  unmarked
>> 0xc000399b00 free  unmarked
>> 0xc000399b60 free  unmarked
>> 0xc000399bc0 free  unmarked
>> 0xc000399c20 free  unmarked
>> 0xc000399c80 free  unmarked
>> 0xc000399ce0 free  unmarked
>> 0xc000399d40 free  unmarked
>> 0xc000399da0 free  unmarked
>> 0xc000399e00 free  unmarked
>> 0xc000399e60 free  unmarked
>> 0xc000399ec0 free  unmarked
>> 0xc000399f20 free  unmarked
>> 0xc000399f80 free  unmarked
>> fatal error: found pointer to free object
>>
>> runtime stack:
>> runtime.throw({0x84f468?, 0xc000399740?})
>> /usr/local/go/src/runtime/panic.go:1047 +0x5d fp=0x7f589bc43780 
>> sp=0x7f589bc43750 pc=0x4357fd
>> runtime.(*mspan).reportZombies(0x7f58c3422308)
>> /usr/local/go/src/runtime/mgcsweep.go:846 +0x2e5 
>> fp=0x7f589bc43800 sp=0x7f589bc43780 pc=0x424d25
>> runtime.(*sweepLocked).sweep(0x7f589bc43928?, 0x0)
>> 

[go-nuts] Re: Re-entrant locks?

[jake...@gmail.com]

Or maybe its because, if the language included them, then people would use 
them. And that is (almost?) always a bad idea. Not providing a tool that 
usually leads to code that is hard to maintain, and often incorrect or 
poorly designed seems to be in line with Go's overall vision. One of the 
reasons  I really like using go is that it allows mediocre programmers to 
write descent, reasonably solid code. And when working on a team it really 
matters, because, lets face it, mediocre developers abound. 

Ian weighed in on reentrant locks back in the early days: 
https://groups.google.com/g/golang-nuts/c/4sx5pPp8gFw/m/afBJTrc7UWIJ. There 
are also many articles on why reentrant locks are evil. Obviously, there 
are those that disagree. 
On Tuesday, February 7, 2023 at 8:41:19 AM UTC-5 ren...@ix.netcom.com wrote:

> I know this topic comes up a bit and I’ve done a bit more research. 
>
> Is a contributing reason that Go does not have re-entrant locks is that Go 
> does not have any way to get Go routine identity? It seems you cannot write 
> a reentrant lock - at least not with the typical syntax - without 
> specialized runtime support. 
>
> The only public way I can think of is something like
>
> somelock.Lock(ctx)
>
> But then you need to make every method accept a context.Context instance. 

-- 
You received this message because you are subscribed to the Google 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/2db39671-485c-4ee1-ab49-28de41969510n%40googlegroups.com.

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

[jake...@gmail.com]

This is pretty OT, and I am no expert, but the overwhelming consensus on 
the inter-tubes seems to be that *reading *from an SSD causes no 'wear' 
whatsoever. It is only writes and deletes that age an SSD. So this use case 
should not impact SSD life. 

But it is an interesting endeavor on its own. 
On Sunday, January 29, 2023 at 1:01:42 AM UTC-5 ren...@ix.netcom.com wrote:

> Shared dynamic libraries do reduce the “wear and tear” on an SSD.  The 
> binaries are loaded a single time and shared across processes - slightly 
> longer startup times for the dynamic linkage. 
>
> It is highly beneficial with large runtimes vs small standard library 
> usage in tiny utilities.  
>
> On Jan 28, 2023, at 10:46 PM, Kurtis Rader  wrote:
>
> 
>
> It does not surprise me that your shared run-time build takes more time 
> than the usual static build. The latter case is highly optimized while your 
> use case has probably been given very little consideration. I am also 
> confused by your argument for supporting linking against a shared Go 
> runtime library. You wrote earlier that the reason you want this is to 
> "reduce ware (sic) and tear on my SSD." I see no reason why linking against 
> a shared Go run-time library would reduce the "wear and tear" on your SSD. 
> I think your premise is flawed.
>
> On Sat, Jan 28, 2023 at 8:29 PM jlfo...@berkeley.edu  
> wrote:
>
>> Thanks for the reply. I had mixed results.
>>
>> On Fedora 37, go version go1.19.4 linux/amd64, in /usr/local/go/src as 
>> root I ran
>>
>> go install -buildmode=shared std
>>
>> That seemed to work.
>>
>> In my normal working directory, as me, not root, I ran
>>
>> go build -linkshared *.go
>>
>> (I do a regular build in this directory by just running "go build *.go")
>>
>> That resulted in a whole bunch of error messages of the style
>>
>> go build internal/goarch: copying /tmp/go-build2481653269/b006/_pkg_.a: 
>> open /usr/local/go/pkg/linux_amd64_dynlink/internal/goarch.a: permission 
>> denied
>>
>> So I became root and ran go build -linkshared *.go again.
>>
>> This time it worked!! The result was 83584 byte binary, whereas the 
>> binary produced 
>> by the standard method is 4186764 bytes. That's a great savings!!! The 
>> small binary seemed
>> to work fine.
>>
>> Just for yuks, I tried building my program as me again (not root). I got 
>> permission error messages
>> again, but now they look like
>>
>> open /usr/local/go/pkg/linux_amd64_dynlink/archive/tar.shlibname: 
>> permission denied
>>
>> There are 238 such lines.
>>
>> There's another problem. Unlike what I would expect, it takes *longer* to 
>> build the shared version
>> than the static version.
>>
>> As root
>>
>> [root@localhost]# time go build *.go
>>
>> real0m0.298s
>> user0m0.346s
>> sys 0m0.091s
>>
>> [root@localhost]# time go build -linkshared *.go
>>
>> real0m1.441s
>> user0m1.193s
>> sys 0m0.325s
>>
>> That doesn't seem right.
>>
>> Any advice?
>>
>> Cordially,
>> Jon Forrest
>>
>> On Saturday, January 28, 2023 at 7:51:25 PM UTC-8 Ian Lance Taylor wrote:
>>
>>> On Sat, Jan 28, 2023 at 11:27 AM jlfo...@berkeley.edu 
>>>  wrote: 
>>> > 
>>> > For people like me who have no intention of ever distributing a Go 
>>> executable, I wonder 
>>> > if it would be useful, and possible, to link to a shared library 
>>> version of the Go 
>>> > Runtime. This would make my binaries much smaller and would reduce 
>>> ware and 
>>> > tear on my SSD. 
>>> > 
>>> > Of course, this presumes that such a shared library could be created 
>>> in the first place. 
>>> > 
>>> > I did a quick Google and I didn't find this issue being previously 
>>> discussed. 
>>> > 
>>> > Comments? 
>>>
>>> At least on Linux systems it should work to run "go install 
>>> -buildmode=shared std" and then to build other Go programs with 
>>> "-linkshared". 
>>>
>>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4dc94780-06e6-4aa3-a9b1-64b97dd85a5en%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...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD-SBB%3DvFGYUGaXpf-8m6RH4HK4xEKjGUdMXMwjK90NMPg%40mail.gmail.com
>  
> 

[go-nuts] Re: dont know how to use library in go

[jake...@gmail.com]

It sounds to me like you are trying to write linux code to load a .so file. 
Not something I have done in a while, but since no one else has offered any 
help, I will give you a few pointers. 

I believe that syscall.LoadDLL  is for Windows only, so that code *will not 
work* at all in linux. 
You will probably need to use CGO (https://pkg.go.dev/cmd/cgo). Sadly CGO 
is difficult, especially for newbies. It is also tricky, so make sure to 
follow the rules laid out. 

Other than that,  I would suggest using a google search like, 
https://www.google.com/search?q=golang+use+so+file and expect a steep 
learning curve.

Good Luck!
On Thursday, January 19, 2023 at 1:04:49 PM UTC-5 Nadia shokkan wrote:

> Hi there,
>
> I'm Nadia from Malaysia. also newbie in Go language. I have a project that 
> already works in windows(my manager do that code), and my manager ask me 
> todo same thing in linux..the project need to use function from .so library 
> given. the problem is i dont know how to do it. btw sorry im still fresh 
> grade. 
>
> I did google and found dl.Open and dlopen. The dl.Open are work, but i 
> dont know how to use the function in the library. dlopen doesnt work in my 
> code..
>
> here is my code
> //original from windows
> dll, err := syscall.LoadDLL("csxapi.dll")
> lib, err := dl.Open("pkg/libcsxapi.so", dl.RTLD_NOW)
> if err != nil {
> log.Fatalf("Instance: failed to load csxapi.dll: %v", err)
> }
>

-- 
You received this message because you are subscribed to the Google 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/055705f6-dbe3-4334-aec0-b76e45b56798n%40googlegroups.com.

[go-nuts] Re: marshalling array of bson.M

[jake...@gmail.com]

You will probably get more help if you provide the relevant details, such 
as which bson package you are using. And provide an *example *that shows 
what you have tried that produces the error. A playground link 
 using the "share" button is the preferred way to 
include examples.

Good Luck.

On Wednesday, January 11, 2023 at 3:19:26 PM UTC-5 RS wrote:

> Is there a possibility to marshal array of bson.M? 
> I get the error: 
> WriteArray can only write a Array while positioned on a Element or Value 
> but is positioned on a TopLevel
>
> My wish is to marshall array ob bason.M objects.
>
> 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/879540b5-98ae-4f65-889b-f6ce11deea6fn%40googlegroups.com.

Re: [go-nuts] How does the go compiler treat initialized string variables?

[jake...@gmail.com]

Just to add a tidbit to what Jan said. The key here is that strings (type 
string) in Go are immutable, whereas strings ("char *"  based types) in C 
are not. That is why the same string can be used again and again without 
ever needing to be copied, and why they can live in the text segment.

On Tuesday, November 1, 2022 at 3:47:47 PM UTC-4 Jan Mercl wrote:

>
>
> On Tue, Nov 1, 2022, 20:36 Frank Jüdes  wrote:
>
>> I have to write a program that should verify the content of 
>> configuration-servers. It will need a lot of pre-initialized data to verify 
>> the actual content of a server, so it has to initialize many strings. What 
>> i know from other C-style languages is, that code like 
>>
>> var MyString *string = 'Hello World!'; 
>>
>> Will result in having two identical copies of the string »Hello World!« 
>> in the memory: The first one within the program-code itself and a second 
>> copy somewhere in the heap-memory.
>>
>
> I think the string backing array will be in the text segment as in C. The 
> string header will end in the data segment, provided it's a package scoped 
> variable, but the header has no direct equivalent in C.
>
> How will the go-compiler handle something like this: 
>>
>> package main 
>>   import ("fmt") 
>>   type MyStruct struct { 
>> Text string 
>> Count int32 
>>   } 
>>   func main() { 
>> MyVar := MyStruct{Text: "Hello World!", Count: 20 } 
>> fmt.Printf("%#v\n",MyVar) } 
>>
>> Will there be two copies of the string »Hello World!" in the memory or 
>> just one? 
>>
>
> The backing string  array will exist only once, again in the text segment, 
> I believe, because there's no reason for making any copies of it in this 
> case.
>
>>
> Not tested/verified 
>
>>
>>

-- 
You received this message because you are subscribed to the Google 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/c44f9c26-f4fe-4e5b-9c33-562b6b490ab8n%40googlegroups.com.

[go-nuts] Re: Atomic pointers to arrays and sequenced-before guarantees for array elements

[jake...@gmail.com]

I would like to give you a definitive answer, but the same question comes 
up in https://groups.google.com/g/golang-nuts/c/Gze1TRtdLdc/ and there is 
much disagreement and no clear resolution. (The initial question is not 
exactly yours, but if I understand correctly, the discussion quickly gets 
simplified to exactly yours.) So unless *someone from the go team is 
willing to clarify,* all you are getting are varying options. Of course, 
read the thread yourself and maybe you will believe one side was correct. 

Reading your description, I am also concerned that you could have a logical 
race. Its possible you already account for this, but if you are setting the 
'array pointer' atomically and separately setting the 'count' atomically, 
the there could be cases where readers read a count not matching the 
current array. There are many simple fixes, and you hopefully have already 
taken this into account, but I just wanted to mention it.

On Sunday, October 30, 2022 at 9:28:49 AM UTC-4 Konstantin Khomoutov wrote:

> Hi!
>
> I would like to receive clarifications, if possible, on Go memory model
> guarantees about non-atomic load and stores when intermixed with atomic 
> load
> and stores.
>
> I'm reviewing a piece of code which, simplified, works as follows:
>
> - There is a single "writer" goroutine which
>
> - Allocates a new array, then uses sync/atomic.StorePointer to save the
> address of this array someplace.
>
> - Writes the array elements one by one.
> After writing each element it - again atomically - updates some memory
> location which contains the number of elements currently written in the
> array.
>
> - When the array fills up, it repeats the routine.
>
> A point to note is that the writer writes each element only once,
> and after it's done with the array, it never touches this array again.
>
> - There are multiple "reader" goroutines each of which consumes the data
> being updated by the "writer" in the following way:
>
> - Use sync/atomic.LoadPointer to obtain the address of the array currently
> in use by the "writer" goroutine.
>
> - Atomically read the current number of elements written in the array
> by the "writer" goroutine and then read that many elements
> from the array.
>
> My problem is that I fail to properly apply the text of the Go memory model
> to this case to figure out if there is still a data race on the elements
> of these arrays between the writer and the readers.
>
> The chief problem I have with my reasoning is that I fail to understand
> whether the sequenced-before guarantees provided by atomics apply only to 
> the
> atomic operations theirselves - and the memory locations they operate on - 
> or
> to the whole sequences of statements executed by goroutines which perform
> the atomic operations.
>
> To simplify, and given the description of the algorithm above, I apply the
> following reasoning.
> A goroutine A performs multiple non-synchronized stores to memory 
> locations X,
> Y and Z, and then performs atomic store into memory location M. Naturally, 
> all
> store operations done on A up to and including the atomic store to M, are
> naturally sequenced - all the non-synchronized stores has happened before 
> the
> atomic store.
> Now a goroutine B uses atomic load of memory location M and then
> performs multiple non-synchronized memory loads from memory locations X, Y
> and Z. These non-synchronized loads are naturally sequenced after the 
> atomic
> load from M.
> ("Naturally sequenced" means it's just a regular program flow within a
> goroutine.)
> Given the above, is it guaranteed that A's stores to X, Y and Z are
> synchronized-before B's loads from X, Y and Z?
>
> My gut feeling is that no, Go does not provide this guarantee because of 
> two
> reasons:
>
> - The store performed by A to M does not depend on stores to X, Y and Z,
> and the compiler and/or the hardware are free to reorder them.
>
> - An atomic store operation is not required to perform a full memory fence,
> so even if no reordering has happened on any layer, the goroutine B
> can still obtain stale data from the CPU cache.
>
> Hence I came to the conclusion that theoretically the code described above 
> is
> still prone to data races on the elements of the arrays.
>
> On the other hand, a sample program implementing the algorithm described 
> above
> compiled with -race does not fail (8-core i7-8550U, linux/amd64, Go 
> 1.17.13;
> also tried other versions). I know that the race detector does only have no
> false positives, but the possibility to detect a particular data race 
> heavily
> depends on the hardware and relative timings of the operations in a running
> program, so the fact it does not see the data race here does not prove it 
> is
> not possible.
>
> So, can anyone please help me analyze this case?
>
> (Well, I also should admit the real code is more complicated than that but 
> the
> basic idea still holds: the implementor has tries to use atomics in the way
> presented in 

Re: [go-nuts] Re: go:embed question

[jake...@gmail.com]

What makes you think that go run github.com/esimov/caire/cmd/caire@latest 
is not embedding properly?
On my system it seems like it works fine, and the file gets embedded. I'm 
using go 1.19 on windows.

Perhaps you could give a more detailed example of what you are doing 
(actual commands) and what you see, and what you actually expect to see. If 
you do that in a way that allows other to replicate you problem, you might 
get a useful response.

On Saturday, October 15, 2022 at 11:49:11 PM UTC-4 esi...@gmail.com wrote:

> go run github.com/esimov/caire/cmd/caire@latest. 
>
> I'm wondering is this somehow related to the fact, that the file which 
> should be embedded is located two levels up to the root tree? The embedable 
> file is located in the data folder, but the file effectively is not 
> embedded in cmd/caire/main.go, but in a file called process.go which is at 
> the same level as the data folder. 
>
> ├───cmd
> │   └───caire/main.go
> ├───data
>
> On Friday, October 14, 2022 at 11:50:18 AM UTC+3 kortschak wrote:
>
>> On Fri, 2022-10-14 at 00:17 -0700, esimov wrote: 
>> > . Now, that's not the case when you are running a package using the 
>> > following command: "go run github.com/user/package@latest" for 
>> > example 
>>
>> Can you give an example of a real package where this doesn't work? 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9108880d-bbd1-4bf0-92e9-a626b70f437dn%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.

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

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.

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.

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

[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 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: 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: 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: 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]{, 1000, 1000}
> var b = Slice1000[int]{, 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.

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.

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, )`
> (
> 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.

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

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.

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

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

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())
> 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 :=  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.

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

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

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

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")
> s2 := make([]uint8, 8)
> aboutSlice(, "s2")
> new_s1 := append(s1, 10)
> new_s2 := append(s2, 20)
> aboutSlice(_s1, "new_s1")
> aboutSlice(_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: 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.

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

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.

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.

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

[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: 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(, , , _stk, , 
> , , , , , 
> )
> 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.

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

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

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.

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

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.

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

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

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

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

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.

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

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

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

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: 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=OpenEventLogW+language%3AGo=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.

[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( )
>
> fmt.Println(" Enter 2nd number:" )
> fmt.Scan( )
> 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: 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: 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: 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: 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", )`. 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", )`. 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 received this 

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

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(, 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} = : 
>> > 9:6: from  (address-of) at ./heap.go:11:8 
>> > 9:6: from F1(, 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  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.

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

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

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

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

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

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=%22windows.WriteFile%22=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: 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.