[go-nuts] Re: An intresting behaviour about number of allocations in []byte->string conversions

[T L]

Sorry, I temporarily switch to Go 1.3.
The result is constantly 0 0 1 for Go 1.15 when N > 2.

On Saturday, August 15, 2020 at 12:30:32 AM UTC-4, T L wrote:
>
>
> package main
>
> import "fmt"
> import "bytes"
> import "testing"
>
> const N = 0
> var name = bytes.Repeat([]byte{'x'}, N)
> var m = make(map[string]string, 10)
> var s string
>
> func f() {
> s = m[string(name)]
> }
>
> func g() {
> key := string(name)
> s = m[key]
> }
>
> func h() {
> m[string(name)] = "Golang"
> }
>
> func main() {
> fmt.Println(testing.AllocsPerRun(1, f)) // 0
> fmt.Println(testing.AllocsPerRun(1, g)) // 1
> fmt.Println(testing.AllocsPerRun(1, h)) // 1
> }
>
> /* The result:
>
> N  fgH
> ------------
> >=9011
> 8,4,2,1,0  000
> 6,7011
> 3,5010
> */
>
> Some inaccuracies in testing.AllocsPerRun?
>

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

[go-nuts] [generics]: Pointer methods in interfaces used as constraints?

[Patrick Smith]

https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#pointer-method-example
has this example:

// Setter2 is a type constraint that requires that the type
// implement a Set method that sets the value from a string,
// and also requires that the type be a pointer to its type parameter.
type Setter2(type B) interface {

Set(string)

type *B

}
// FromStrings2 takes a slice of strings and returns a slice of T,
// calling the Set method to set each returned value.
//
// We use two different type parameters so that we can return
// a slice of type T but call methods on *T aka PT.
// The Setter2 constraint ensures that PT is a pointer to T.
func FromStrings2(type T interface{}, PT Setter2(T))(s []string) []T {

result := make([]T, len(s))

for i, v := range s {

// The type of &result[i] is *T which is in the type list

// of Setter2, so we can convert it to PT.

p := PT(&result[i])

// PT has a Set method.

p.Set(v)

}

return result

}


I wonder if it might be worthwhile to allow specifying pointer methods in
interfaces, so that we could write instead

type Setter3 interface {

// For type T to implement Setter3, *T must have a Set method.

* Set(string)

}

func FromStrings3(type T Setter3(T))(s []string) []T {

result := make([]T, len(s))

for i, v := range s {

result[i].Set(v)

}

}


This is simpler in two ways: FromStrings3 only needs one interface
constraint, and it does not need to convert &result[i] to a type parameter,
but can call result[i].Set(v) directly.

I imagine interfaces containing pointer methods should be used only as
constraints on type parameters, not as normal interfaces.

I have no idea if such cases arise often enough to make this idea
worthwhile.

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

[go-nuts] An intresting behaviour about number of allocations in []byte->string conversions

[T L]

package main

import "fmt"
import "bytes"
import "testing"

const N = 0
var name = bytes.Repeat([]byte{'x'}, N)
var m = make(map[string]string, 10)
var s string

func f() {
s = m[string(name)]
}

func g() {
key := string(name)
s = m[key]
}

func h() {
m[string(name)] = "Golang"
}

func main() {
fmt.Println(testing.AllocsPerRun(1, f)) // 0
fmt.Println(testing.AllocsPerRun(1, g)) // 1
fmt.Println(testing.AllocsPerRun(1, h)) // 1
}

/* The result:

N  fgH
------------
>=9011
8,4,2,1,0  000
6,7011
3,5010
*/

Some inaccuracies in testing.AllocsPerRun?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/44bdea3f-762e-4200-9283-de318d7393a1o%40googlegroups.com.

Re: [go-nuts] Generics: after type lists

[Patrick Smith]

On Thu, Aug 13, 2020 at 11:25 PM Patrick Smith  wrote:
> I tried out a few different implementations, evaluating the polynomial
> instead of finding roots,
> at https://go2goplay.golang.org/p/g8bPHdg5iMd . As far as I can tell,
> there is no sensible way to
> do it with an interface that is implemented directly by *big.Float; we
> need to wrap *big.Float
> in a wrapper type in any case.

After looking at the draft again, and seeing the Settable example
there, I realized we can do it using big.Float directly, but it needs
two interfaces, one matching big.Float and one matching *big.Float. I
have updated my examples at https://go2goplay.golang.org/p/auSkvhWSNHn
.

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

[go-nuts] The latest version of package in pkg.go.dev

[Tong Sun]

How to force update the latest version of package in pkg.go.dev?

My https://github.com/go-easygen/easygen/releases/tag/v5.1.01 has been 
release for over 10 days, but the 
https://pkg.go.dev/github.com/go-easygen/easygen?tab=versions is still 
showing an old version. 

>From https://proxy.golang.org/ I saw

explicitly request that version via go get module@version. After one minute 
> for caches to expire, the go command will see that tagged version. If this 
> doesn't work for you, please file an issue 
> .



So I did:


go get github.com/go-easygen/easygen@v5.1.01

go: downloading github.com/go-easygen/easygen 
v4.0.1-0.20200804033944-7bacacfacf6a+incompatible
go: github.com/go-easygen/easygen v5.1.01 => 
v4.0.1-0.20200804033944-7bacacfacf6a+incompatible
go: finding module for package gopkg.in/yaml.v2
. . . 

$ date
Fri Aug 14 21:56:06 EDT 2020

$ lynx -dump 
-width=78 "https://pkg.go.dev/github.com/go-easygen/easygen?tab=versions";; 
date
. . . 
v1 - github.com/go-easygen/easygen

 * [32]v4.1.0+incompatible - Jun 19, 2019
 * [33]v4.0.0+incompatible - Mar 24, 2019
 * [34]v3.0.0+incompatible - May 4, 2018
. . . 
Fri Aug 14 22:06:18 EDT 2020


So do I need to file an issue 
, or I've missed 
something? 

Thx


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0854db20-1596-4709-930d-23ddde7063f9o%40googlegroups.com.

Re: [go-nuts] Re: module confusion

[Marvin Renich]

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

While (I believe) the majority of individuals (rather than sysadmins)
installing on Linux, MacOS, and FreeBSD will be the primary (essentially
sole) user on such systems, and will be able to use /usr/local (usually
requiring su or sudo or modifying permissions on /usr/local, which is
not mentioned in the above referenced instructions), this is not a
universal condition.  Especially, students at universities using an
account on a university machine will generally not have access to
/usr/local.  I think this is a significant enough use case to warrant a
mention in the installation instructions, e.g.

  If you do not have access to /usr/local, or do not wish to install
  there, you may install to another directory, such as $HOME/goroot.
  The directory $HOME should not be used, as this would make $GOROOT the
  same as the default $GOPATH ($HOME/go), which is not allowed.

Anything along these lines would help alleviate the confusion that the
OP had.

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

...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/20200814233137.dujkksays2luoqyt%40basil.wdw.

Re: [go-nuts] [ generics ] Concrete example of comparables and generic function types

[Beka Westberg]

> Thanks for the example.

My pleasure :D Thank you for taking a look!

> Nice example! Presumably if you wanted to do actual Porter-Duff though, 
you'd want some arithmetic rather than just comparison.

Thank you! And yeah if you wanted to do something like a color-dodge or 
other blend modes you'd definitely need more operations =)

> One observation: you don't actually need the "comparable" constraint on 
many of the core entities there (e.g. Rect and Op) because they don't 
actually use any compare operations. The code works just fine if you omit 
them: https://go2goplay.golang.org/p/dKGOaN_v3He

Good point! All Merge requires is that it accepts and returns the given 
type, no need to force anything to be comparable at that level :D

> Technically, the "z" argument to Op isn't necessary either AFAICS - you 
could just use a zero value instead (unless you actually want to be able to 
have a non-zero "zero" value, I guess).

Yeah in this example it's not needed because you just pass 0 hehe, but I 
wanted to include it because you can make some pretty cool combinations if 
you change it. Here's  a little 
example.

But thinking about it... really there's no reason Merge should be passing 
the zero value around. It's perfectly reasonable to have an Op function 
that doesn't require one. For example an averaging function 
. It probably makes more sense 
to wrap the functions that do require zero values in a closure, as in this 
example . (I know some of those 
functions don't require z values, but I wanted them to have a uniform type 
:D)

Thank you for your feedback!
--Beka
On Friday, August 14, 2020 at 3:18:14 PM UTC-7 rog wrote:

> Nice example! Presumably if you wanted to do actual Porter-Duff though, 
> you'd want some arithmetic rather than just comparison.
>
> One observation: you don't actually need the "comparable" constraint on 
> many of the core entities there (e.g. Rect and Op) because they don't 
> actually use any compare operations. The code works just fine if you omit 
> them: https://go2goplay.golang.org/p/dKGOaN_v3He
>
> Technically, the "z" argument to Op isn't necessary either AFAICS - you 
> could just use a zero value instead (unless you actually want to be able to 
> have a non-zero "zero" value, I guess).
>
>   cheers,
> rog.
>
>
> On Fri, 14 Aug 2020 at 04:37, Beka Westberg  wrote:
>
>> Hello! I just ran into a problem that is solved really nicely with the 
>> new generics proposal and I thought someone might find it interesting :D
>>
>> I was trying to implement a library for doing ascii art programmatically. 
>> The main struct is basically an image.Image except it works with bytes 
>> instead of colors. As such you /should/ be able to create functions (like a 
>> flood fill algorithm) that are abstracted over both of these types, but 
>> without "generics" this cannot be done (with compile time type safety).
>>
>> I sketched a little project  
>> in the go2go playground that implements generic functions for doing 
>> Porter-Duff 
>> compositions  on any types 
>> that fulfill the following constraint:
>>
>> ```
>> type Rect(type T comparable) interface {
>> At(x, y int) T
>> Set(x, y int, t T)
>> }
>> ```
>>
>> Type defs on lines [8, 13]. Porter-Duff implementation [15, 99] Main 
>> [101, 108] ByteImg implementation [110, 185]
>>
>> I liked this example because it requires passing a generic function (the 
>> Porter-Duff func) to another generic function (Merge) :D I hope someone 
>> else finds it interesting as well!
>> --Beka
>>
>> -- 
>> You received this message because you are subscribed 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/dbc90697-e276-437b-ab39-b52564fc6d5an%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/a9b2384f-b6c7-4c46-a9a3-2b8237c1b92cn%40googlegroups.com.

[go-nuts] basics of understanding golang memory usage

[Mike Spreitzer]

I have several basic questions.  I examined a couple of golang programs, 
and got really confused.

I started by looking at a kube-proxy from Kubernetes release 1.15 (probably 
either 1.15.9 or 1.15.12) on Linux 4.15.0 using `/proc/[pid]/statm`.  
As a reminder, here is what man procfs has to say about that:

  Provides information about memory usage, measured in pages.  The
  columns are:
  size   (1) total program size
 (same as VmSize in /proc/[pid]/status)
  resident   (2) resident set size
 (same as VmRSS in /proc/[pid]/status)
  shared (3) number of resident shared pages (i.e., backed 
by a file)
 (same as RssFile+RssShmem in /proc/[pid]/status)
  text   (4) text (code)
  lib(5) library (unused since Linux 2.6; always 0)
  data   (6) data + stack
  dt (7) dirty pages (unused since Linux 2.6; always 0)

Here is what I saw:

/proc/10368$ cat statm
35207 8684 6285 4026 0 26265 0

The page size is 4 KiB.  That’s about 16 MB of code plus 108 MB of 
data+stack, plus another 20 MB of something else.  What is that something 
else?  Why is the data+stack so huge?

Next I looked at `maps`:

/proc/10368$ sudo cat maps

0040-013ba000 r-xp  fc:01 777880 
/usr/local/bin/kube-proxy

013ba000-026e9000 r--p 00fba000 fc:01 777880 
/usr/local/bin/kube-proxy

026e9000-02749000 rw-p 022e9000 fc:01 777880 
/usr/local/bin/kube-proxy

02749000-0277 rw-p  00:00 0 

c0-c00020 rw-p  00:00 0 

c00020-c00040 rw-p  00:00 0 

c00040-c000a0 rw-p  00:00 0 

c000a0-c00400 rw-p  00:00 0 

7f4b47346000-7f4b49937000 rw-p  00:00 0 

7ffcd6169000-7ffcd618a000 rw-p  00:00 0  [stack]

7ffcd61d-7ffcd61d3000 r--p  00:00 0  [vvar]

7ffcd61d3000-7ffcd61d5000 r-xp  00:00 0  [vdso]

ff60-ff601000 r-xp  00:00 0  
[vsyscall]


The block from c0 to c00400 is about 67 MB, and the block from 
7f4b47346000 to 7f4b49937000 is about another 40 MB.  So that must be most 
of the 108 MB data+stack.  The fact that they are distinct memory ranges 
suggest they are two different kinds of usage.  Which range is which usage?


The first block for /usr/local/bin/kube-proxy is the 4026 pages that procfs 
reports for text.  Why are the other two /usr/local/bin/kube-proxy blocks 
not reported as text?  They add up to about that mysterious 20 MB.  Is the 
first block included in "number of resident shared pages (i.e., backed by a 
file)"?

Next, I tried scraping /metrics from a different golang process.  I have 
lots of questions about the memory related metrics.  Is there any more 
definition of the go_memstats_… metrics beyond their HELP lines?

For example, what is the difference beween

# HELP go_memstats_heap_alloc_bytes Number of heap bytes allocated and still in 
use.
# TYPE go_memstats_heap_alloc_bytes gauge
go_memstats_heap_alloc_bytes 4.881872e+06

and

# HELP go_memstats_heap_inuse_bytes Number of heap bytes that are in use.
# TYPE go_memstats_heap_inuse_bytes gauge
go_memstats_heap_inuse_bytes 7.33184e+06

?

It clearly is not

# HELP go_memstats_heap_idle_bytes Number of heap bytes waiting to be used.
# TYPE go_memstats_heap_idle_bytes gauge
go_memstats_heap_idle_bytes 5.885952e+07

… and what is that, anyway?

And then there is this:

# HELP go_memstats_heap_released_bytes Number of heap bytes released to OS.
# TYPE go_memstats_heap_released_bytes gauge
go_memstats_heap_released_bytes 5.7155584e+07

… is that “released” as in “cumulative over release operations in the past” 
or as in “currently in released-to-os state”?

Same question for “obtained” in

# HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from system.
# TYPE go_memstats_heap_sys_bytes gauge
go_memstats_heap_sys_bytes 6.619136e+07


Then there is

# HELP go_memstats_stack_inuse_bytes Number of bytes in use by the stack 
allocator.
# TYPE go_memstats_stack_inuse_bytes gauge
go_memstats_stack_inuse_bytes 917504

does “use by the stack allocator” refer to overhead of the allocator, or 
use for stacks themselves?

There are several metrics described as being “obtained from system” for 
various purposes, but they do not add up to what appears to be the total.

# HELP go_memstats_heap_sys_bytes Number of heap bytes obtained from system.
# TYPE go_memstats_heap_sys_bytes gauge
go_memstats_heap_sys_bytes 6.619136e+07

# HELP go_memstats_mcache_sys_bytes Number of bytes used for mcache structures 
obtained from system.
# TYPE go_memstats_mcache_sys_bytes gauge
go_memstats_mcache_sys_bytes 16384

# HELP go

Re: [go-nuts] [ generics ] Concrete example of comparables and generic function types

[roger peppe]

Nice example! Presumably if you wanted to do actual Porter-Duff though,
you'd want some arithmetic rather than just comparison.

One observation: you don't actually need the "comparable" constraint on
many of the core entities there (e.g. Rect and Op) because they don't
actually use any compare operations. The code works just fine if you omit
them: https://go2goplay.golang.org/p/dKGOaN_v3He

Technically, the "z" argument to Op isn't necessary either AFAICS - you
could just use a zero value instead (unless you actually want to be able to
have a non-zero "zero" value, I guess).

  cheers,
rog.


On Fri, 14 Aug 2020 at 04:37, Beka Westberg  wrote:

> Hello! I just ran into a problem that is solved really nicely with the new
> generics proposal and I thought someone might find it interesting :D
>
> I was trying to implement a library for doing ascii art programmatically.
> The main struct is basically an image.Image except it works with bytes
> instead of colors. As such you /should/ be able to create functions (like a
> flood fill algorithm) that are abstracted over both of these types, but
> without "generics" this cannot be done (with compile time type safety).
>
> I sketched a little project 
> in the go2go playground that implements generic functions for doing 
> Porter-Duff
> compositions  on any types
> that fulfill the following constraint:
>
> ```
> type Rect(type T comparable) interface {
> At(x, y int) T
> Set(x, y int, t T)
> }
> ```
>
> Type defs on lines [8, 13]. Porter-Duff implementation [15, 99] Main [101,
> 108] ByteImg implementation [110, 185]
>
> I liked this example because it requires passing a generic function (the
> Porter-Duff func) to another generic function (Merge) :D I hope someone
> else finds it interesting as well!
> --Beka
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/dbc90697-e276-437b-ab39-b52564fc6d5an%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/CAJhgacjmxWC361xC-W4zTrw%3D6nO-%2BhRi0UVRAWSYKqRBkHfw2w%40mail.gmail.com.

Re: [go-nuts] [ generics ] Concrete example of comparables and generic function types

[Ian Lance Taylor]

On Thu, Aug 13, 2020 at 8:37 PM Beka Westberg  wrote:
>
> Hello! I just ran into a problem that is solved really nicely with the new 
> generics proposal and I thought someone might find it interesting :D
>
> I was trying to implement a library for doing ascii art programmatically. The 
> main struct is basically an image.Image except it works with bytes instead of 
> colors. As such you /should/ be able to create functions (like a flood fill 
> algorithm) that are abstracted over both of these types, but without 
> "generics" this cannot be done (with compile time type safety).
>
> I sketched a little project in the go2go playground that implements generic 
> functions for doing Porter-Duff compositions on any types that fulfill the 
> following constraint:
>
> ```
> type Rect(type T comparable) interface {
> At(x, y int) T
> Set(x, y int, t T)
> }
> ```
>
> Type defs on lines [8, 13]. Porter-Duff implementation [15, 99] Main [101, 
> 108] ByteImg implementation [110, 185]
>
> I liked this example because it requires passing a generic function (the 
> Porter-Duff func) to another generic function (Merge) :D I hope someone else 
> finds it interesting as well!

Thanks for the example.

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/CAOyqgcUWF7c3kvJa-c%3DTTw9Cdccbcz%3D9A%2BKDxpdSBaWgjrtymw%40mail.gmail.com.

Re: [go-nuts] How to build an object file for a specific GOOS and GOARCH with external linker?

[Ian Lance Taylor]

On Fri, Aug 14, 2020 at 8:29 AM  wrote:
>
> i'm trying to create an object file by using "go build" for GOOS=linux 
> GOARCH=386.
> My current go environment has GOOS=linux GOARCH=amd64.
>
> i know that go build directly builds and links the files, but i want to link 
> files using an external linker file, so i need only the object file to be 
> created.
>
> i have tried to look up ways to do so, but i could not find any solution to 
> this.
>
> The files i'm trying to compile can be .go files that have a main function or 
> just a non-main-package.

There is no way to do this for a non-main package.  I'm not sure how
that makes sense.  There wouldn't be any way for you to use such an
object.

For a main package, one trick to get you started is to use to use go
build -ldflags="-linkmode=external -extld=/bin/echo".  That will show
you how the external linker is invoked, including the objects that are
passed to it.  If you also use the go build -work option, it will save
the temporary directory, and you can grab the objects.  Then in
principle you can copy those objects to the target system and run the
linker command there.

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

Re: [go-nuts] Re: module confusion

['K Richard Pixley' via golang-nuts]

On 8/14/20 11:54, 'Carla Pfaff' via golang-nuts wrote:
People and installers usually install Go in /usr/local/go on Unix-like 
systems.


~/go is the default GOPATH if not set, so ~/go/bin is where binaries 
installed via "go get" / "go install" land. But the Go distribution 
itself must not be under GOPATH.


Thank you for the clarification.

I think that's exceeding confusing and needs much better documentation.

In particular, I think the installation instructions should suggest a 
private install location if the obvious one isn't useful.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/837af448-8a1c-7c27-3280-cddc15b9fd5e%40juniper.net.

Re: [go-nuts] map without default values

['Axel Wagner' via golang-nuts]

On Fri, Aug 14, 2020 at 8:52 PM Joe Marty 
wrote:

>
>> If I know that a value exists, or am fine using the zero value (again,
>> that's the majority of my personal use-cases for maps at least), having to
>> use a statement just to discard the extra bool is annoying.
>>
>
> Right, so this brings me back to a nice solution to both our use cases,
> which would be to initialize the map as either having a default or not
> having a default.  You don't have to check for failure, I don't have to
> worry about forgetting to check for failure... right? :D
>

Oh, sorry, I didn't catch that. The problem with that is that this is a
pretty significant behavioral difference, so it at least would need to be
reflected in the type (as you clarify). Having two different map types
seems overkill to me.

It would definitely be *possible*. And if the problem was large enough, I
might support the idea. But I don't feel it is, one way or another. Like, I
would rather have a map-type which always panics, than have two
different ones.


>
> FWIW, using `map[K]bool` as a set is a great example for where this
>> behavior is super convenient. Far more convenient than if you use
>> `map[K]struct{}`, which has significant syntactical overhead.
>>
>
> Sure, that's a bad alternative.  So again, back to my original theory,
> seems like an overall better option to have `map[K]bool(false)` if you want
> the default to be false vs `map[K]bool` if you don't.  Or perhaps
> `openMap[K]bool` if you want every key to return something vs
> `closedMap[K]bool` if you don't.
>
>
>> Well, an exception-based language of course is less hesitant to throw
>> exceptions. But as a result, they often get ignored and cause crashes with
>> useless stack traces (useless to the user, that is - the developer might
>> find them more useful, but as a user, I want to know what I did wrong
>> *without* having to look at source code).
>>
>
> Fair point :)
>
> I suppose maybe there's a way to setup a style linter to enforce a failure
>>> check for every map access?  (But that's a lot more tedious than just
>>> enabling a default where appropriate, or disabling it where it's not...)
>>>
>>
>> It's something you could do for your code base, for sure. But personally,
>> I'd consider doing that bad style. Only check for membership, if membership
>> is actually important.
>>
>
> Well I definitely agree there about the ideal state - I should only have
> to check for membership when membership is important ideally.  So wouldn't
> it also be ideal to allow the developer to indicate when membership is
> important vs when it's not upon initialization, so that the runtime can
> panic when panic is appropriate, and just move along when "there's nothing
> to see here" - all without requiring any convention or ongoing discernment
> from maintainers of a code-base?
>
> (And maybe not even panic, but just require checking for failure in one
> case, but not in the other, so that mistakes can be caught at compile
> time!) :D
>
>
>
>
>
>
>
>
> *Connect with us here:* LinkedIn
> , Facebook
> , Instagram
> , Twitter
> , BuiltInAustin
> 
>
> [image: https://www.smartersorting.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/e2636a6e-8478-44eb-bc44-e0b0a8d3b5cbn%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/CAEkBMfF0pG13LMOqURCgD9CmMjriAyBVPmxDHtj%3Djy21q5YHvA%40mail.gmail.com.

Re: [go-nuts] Re: module confusion

['Carla Pfaff' via golang-nuts]

People and installers usually install Go in /usr/local/go on Unix-like 
systems.

~/go is the default GOPATH if not set, so ~/go/bin is where binaries 
installed via "go get" / "go install" land. But the Go distribution itself 
must not be under GOPATH.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fb4aeee2-53fd-49cd-b42c-b247ad332e4bn%40googlegroups.com.

Re: [go-nuts] Re: module confusion

[Volker Dobler]

On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
>
> Isn't this the default location?  I just untarred the distribution... 
>

No. There is a reason https://golang.org/doc/install#install
states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz

V.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74cf0d07-3d1a-4029-888c-74d8addcb891o%40googlegroups.com.

Re: [go-nuts] map without default values

[Joe Marty]

>
>
> If I know that a value exists, or am fine using the zero value (again, 
> that's the majority of my personal use-cases for maps at least), having to 
> use a statement just to discard the extra bool is annoying.
>
  
Right, so this brings me back to a nice solution to both our use cases, 
which would be to initialize the map as either having a default or not 
having a default.  You don't have to check for failure, I don't have to 
worry about forgetting to check for failure... right? :D

FWIW, using `map[K]bool` as a set is a great example for where this 
> behavior is super convenient. Far more convenient than if you use 
> `map[K]struct{}`, which has significant syntactical overhead.
>

Sure, that's a bad alternative.  So again, back to my original theory, 
seems like an overall better option to have `map[K]bool(false)` if you want 
the default to be false vs `map[K]bool` if you don't.  Or perhaps 
`openMap[K]bool` if you want every key to return something vs 
`closedMap[K]bool` if you don't.
 

> Well, an exception-based language of course is less hesitant to throw 
> exceptions. But as a result, they often get ignored and cause crashes with 
> useless stack traces (useless to the user, that is - the developer might 
> find them more useful, but as a user, I want to know what I did wrong 
> *without* having to look at source code).
>
 
Fair point :)

I suppose maybe there's a way to setup a style linter to enforce a failure 
>> check for every map access?  (But that's a lot more tedious than just 
>> enabling a default where appropriate, or disabling it where it's not...)
>>
>
> It's something you could do for your code base, for sure. But personally, 
> I'd consider doing that bad style. Only check for membership, if membership 
> is actually important.
>

Well I definitely agree there about the ideal state - I should only have to 
check for membership when membership is important ideally.  So wouldn't it 
also be ideal to allow the developer to indicate when membership is 
important vs when it's not upon initialization, so that the runtime can 
panic when panic is appropriate, and just move along when "there's nothing 
to see here" - all without requiring any convention or ongoing discernment 
from maintainers of a code-base?

(And maybe not even panic, but just require checking for failure in one 
case, but not in the other, so that mistakes can be caught at compile 
time!) :D








-- 
*Connect with us here:* LinkedIn 
, Facebook 
, Instagram 
, Twitter 
, BuiltInAustin 



 
 


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

Re: [go-nuts] Go1.15 + SQLite Driver + Windows + Ld.exe results in ld error "unrecognized option --high-entropy-va"

[Sean O'Neil]

Never mind, I just noticed the original post answered it. Sorry, read it 
too quickly.


On Thursday, August 13, 2020 at 3:13:51 PM UTC-4 Ian Lance Taylor wrote:

> On Thu, Aug 13, 2020 at 12:01 PM Corey Gilmore  
> wrote:
> >
> > Setup:
> > - Go 1.15
> > - https://github.com/mattn/go-sqlite3 SQL driver
> > - Windows 10 (2004)
> > - Ld.exe (via MingW via TDM-GCC), version 2.25
> >
> > Prior to go1.15, running "go run main.go" or "go build" would work 
> without issue. With go1.15, the error "ld.exe: unrecognized option 
> '--high-entropy-va'" occurs. This seems to be due to go1.15 changing the 
> default buildmode from exe to pie (https://golang.org/doc/go1.15#windows) 
> as setting the buildmode (-buildmode=exe) when running "go run" or "go 
> build" resolves the issue.
> >
> > Looking into ld.exe, I do see that the "--high-entropy-va" flag is 
> available although the error says it is unrecognized. Odd...but this is 
> also outside of my wheelhouse.
> >
> > Running/building on WSL or Ubuntu using go1.15 works without issue. This 
> is strictly a Windows issue and specifically because of SQLite since it 
> requires cgo.
>
> The --high-entropy-va option was added to the MingW linker in the GNU
> binutils 2.26 release. You are using 2.25, which was released in
> 2014. The current version is 2.35. Is it possible for you to upgrade
> to a newer version?
>
> 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/f5238ef9-4a97-4be2-9028-5fa9fe7ecdf9n%40googlegroups.com.

Re: [go-nuts] Go1.15 + SQLite Driver + Windows + Ld.exe results in ld error "unrecognized option --high-entropy-va"

[Sean O'Neil]

Just upgraded from 1.12 to 1.15 and ran into this as well. What about those 
of us who can't so easily upgrade the version of MingW we're using?

Is there no way to disable that option when building cgo projects from the 
command-line? If not, does 1.14 use it, or do I have to go back even 
farther to get it working again?

Thanks,
Sean


On Thursday, August 13, 2020 at 3:13:51 PM UTC-4 Ian Lance Taylor wrote:

> On Thu, Aug 13, 2020 at 12:01 PM Corey Gilmore  
> wrote:
> >
> > Setup:
> > - Go 1.15
> > - https://github.com/mattn/go-sqlite3 SQL driver
> > - Windows 10 (2004)
> > - Ld.exe (via MingW via TDM-GCC), version 2.25
> >
> > Prior to go1.15, running "go run main.go" or "go build" would work 
> without issue. With go1.15, the error "ld.exe: unrecognized option 
> '--high-entropy-va'" occurs. This seems to be due to go1.15 changing the 
> default buildmode from exe to pie (https://golang.org/doc/go1.15#windows) 
> as setting the buildmode (-buildmode=exe) when running "go run" or "go 
> build" resolves the issue.
> >
> > Looking into ld.exe, I do see that the "--high-entropy-va" flag is 
> available although the error says it is unrecognized. Odd...but this is 
> also outside of my wheelhouse.
> >
> > Running/building on WSL or Ubuntu using go1.15 works without issue. This 
> is strictly a Windows issue and specifically because of SQLite since it 
> requires cgo.
>
> The --high-entropy-va option was added to the MingW linker in the GNU
> binutils 2.26 release. You are using 2.25, which was released in
> 2014. The current version is 2.35. Is it possible for you to upgrade
> to a newer version?
>
> 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/9c39364b-ec3a-4805-89ab-3e00d0f0a800n%40googlegroups.com.

Re: [go-nuts] Re: module confusion

['K Richard Pixley' via golang-nuts]

On 8/14/20 11:27, 'Carla Pfaff' via golang-nuts wrote:
This has nothing to do with modules. You're still using the old GOPATH 
mode, because you're not in a directory with a go.mod file. GOPATH 
defaults to $HOME/go when it's not set (since 1.8), but that's where 
you chose to put your Go installation. This is not allowed. Either 
install Go to a different location, or set GOPATH to a different location.


Isn't this the default location?  I just untarred the distribution...

The default gobin is ~/go/bin, no?  So I should be untarring in ~, no?

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/394cb232-e392-3ce7-077d-775ad17598e2%40juniper.net.

[go-nuts] Re: module confusion

['Carla Pfaff' via golang-nuts]

This has nothing to do with modules. You're still using the old GOPATH 
mode, because you're not in a directory with a go.mod file. GOPATH defaults 
to $HOME/go when it's not set (since 1.8), but that's where you chose to 
put your Go installation. This is not allowed. Either install Go to a 
different location, or set GOPATH to a different location.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/722d0683-ceaf-4e7e-81a5-996e9abc5fabn%40googlegroups.com.

Re: [go-nuts] module confusion

['K Richard Pixley' via golang-nuts]

On 8/14/20 11:20, Jan Mercl wrote:

[External Email. Be cautious of content]


On Fri, Aug 14, 2020 at 8:03 PM 'K Richard Pixley' via golang-nuts
 wrote:


What am I missing?
package github.com/mna/pigeon: cannot download, $GOPATH must not be set to 
$GOROOT. For more details see: 'go help gopath'

The above is the problem


GOPATH="/homes/kpixley/go"
GOROOT="/homes/kpixley/go"

The above is the proof.

Check where $GOPATH got set to the same value as $GOROOT (or vice
versa). Possibly in ~/.profile or ~/.bashrc. If not, check the output
of `go env` in a newly opened terminal window if the problem persists.
If not, it might have been set manually just in your current terminal.


Showed that in my output.  Neither are set.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/214add94-c4af-319c-78ea-89c790ba1207%40juniper.net.

Re: [go-nuts] module confusion

[Jan Mercl]

On Fri, Aug 14, 2020 at 8:03 PM 'K Richard Pixley' via golang-nuts
 wrote:

> What am I missing?

> package github.com/mna/pigeon: cannot download, $GOPATH must not be set to 
> $GOROOT. For more details see: 'go help gopath'

The above is the problem

> GOPATH="/homes/kpixley/go"

> GOROOT="/homes/kpixley/go"

The above is the proof.

Check where $GOPATH got set to the same value as $GOROOT (or vice
versa). Possibly in ~/.profile or ~/.bashrc. If not, check the output
of `go env` in a newly opened terminal window if the problem persists.
If not, it might have been set manually just in your current terminal.

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

[go-nuts] module confusion

['K Richard Pixley' via golang-nuts]

I'm consistently finding modules confusing.

Here's today's confusion.  I /think/ I've eliminated local environment 
settings but, once done, go get isn't working and I don't understand 
what needs to be changed.  What am I missing?


kpixley@editsb> type go
-bash: type: go: not found
kpixley@editsb> PATH=$PATH:${HOME}/go/bin ; export PATH

kpixley@editsb> type go
go is hashed (/homes/kpixley/go/bin/go)
kpixley@editsb> go version
go version go1.15 linux/amd64
kpixley@editsb> go get -u github.com/mna/pigeon
package github.com/mna/pigeon: cannot download, $GOPATH must not be set 
to $GOROOT. For more details see: 'go help gopath'

kpixley@editsb> ls .config/go
ls: cannot access '.config/go': No such file or directory
kpixley@editsb> ls /usr/local/go/bin
ls: cannot access '/usr/local/go/bin': No such file or directory
kpixley@editsb> echo $GOPATH

kpixley@editsb> echo $GOROOT

kpixley@editsb> go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/homes/kpixley/.cache/go-build"
GOENV="/homes/kpixley/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/homes/kpixley/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/homes/kpixley/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct";
GOROOT="/homes/kpixley/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/homes/kpixley/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
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-build515552229=/tmp/go-build 
-gno-record-gcc-switches"


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/f30faa82-6d5f-55e7-f065-3add937eeb01%40juniper.net.

Re: [go-nuts] map without default values

['Axel Wagner' via golang-nuts]

On Fri, Aug 14, 2020 at 6:17 PM Joe Marty 
wrote:

> Yeah, I can see how the convention of "always testing for failure" is
> better than a panic, in that it requires you to handle the possibility of a
> failure for things that may commonly fail.  In that respect though, I don't
> understand why the "comma OK" is optional.
>

Because you want index-accesses as an expression with a single value (say,
when passing it as a function argument). If I know that a value exists, or
am fine using the zero value (again, that's the majority of my personal
use-cases for maps at least), having to use a statement just to discard the
extra bool is annoying.


> Elm, for instance, handles things similarly, and has no panics or errors
> at all as a result because it enforces handling of every possible outcome.
> But in Go, it seems like... in places where it's not easy to use "comma OK"
> (maybe in the middle of a larger expression), or if I forget, I could
> easily confuse the default result from a boolean map (false) with an actual
> false value!
>

FWIW, using `map[K]bool` as a set is a great example for where this
behavior is super convenient. Far more convenient than if you use
`map[K]struct{}`, which has significant syntactical overhead.

In Python or Elm, or Ruby, there would be a clear distinction and/or a
> panic.
>

Well, an exception-based language of course is less hesitant to throw
exceptions. But as a result, they often get ignored and cause crashes with
useless stack traces (useless to the user, that is - the developer might
find them more useful, but as a user, I want to know what I did wrong
*without* having to look at source code).

Throwing an exception is a fine approach, if your language works that way.
But "other languages are doing it" isn't a super good argument for doing
the same - if it was, we only had one language.

I agree that it's not a common case that you might want a panic - in fact I
> *never* want a panic, haha!  I suppose it's more of a question of language
> convention vs. language enforcement.  Because I'm human, and rarely write
> perfect code, I would prefer for the compiler (or the runtime environment)
> to have an error if I make a mistake like that.
>

There's a tradeoff going on, between readability (and writability) and
safety. Requiring people to litter code with extra statements or
_-assignments might make things a little bit safer, but it also makes code
a little less readable.

Which is not to say that other tradeoffs aren't valid as well, but this is
the one Go chose.

I suppose maybe there's a way to setup a style linter to enforce a failure
> check for every map access?  (But that's a lot more tedious than just
> enabling a default where appropriate, or disabling it where it's not...)
>

It's something you could do for your code base, for sure. But personally,
I'd consider doing that bad style. Only check for membership, if membership
is actually important.


>
> On Thursday, August 13, 2020 at 2:11:47 PM UTC-5 Michael Jones wrote:
>
>> Joe, your question is perfectly answered by Axel.
>>
>> I'll just share a few (personal) Go "style" comments:
>>
>> Go likes you to test explicitly for failure where that is possible: did
>> the open fail, did the pipe break, etc.Multiple return values make this
>> clear by avoiding the need for a "reserved" error value of the normal-case
>> return.
>>
>> Go likes untested actions to work. In your case adding an existing key to
>> a map replaces the old entry, accessing a missing entry returns the default
>> value. ["no surprises"]
>>
>> Go likes you to combine these approaches to make your own more elaborate
>> behaviors using the "comma OK" approach that Axel shared. In your case,
>> adding, and deleting could complain if there is already a matching entry,
>> or not a matching entry, or -- and this is the real reason -- by looking at
>> the payload of a new or matching entry to use application logic to decide
>> if that's ok or not. Only you can know so Go won't second guess you, and
>> the test-rather-than-panic style is because testing right there is deemed
>> the right way.
>>
>>
>> On Thu, Aug 13, 2020 at 11:42 AM 'Axel Wagner' via golang-nuts <
>> golan...@googlegroups.com> wrote:
>>
>>> No, there isn't, but you can check if the value exists:
>>>
>>> x, ok := m[k]
>>> if !ok {
>>> panic("does not exist")
>>> }
>>>
>>> You can also wrap that with methods, if you want to avoid the extra
>>> check.
>>>
>>> I disagree with you that panicking on a non-existent key is better -
>>> either in general, or in the majority of cases. Personally, I don't think I
>>> encountered many use-cases where the zero-value wasn't the perfect thing to
>>> use. I'm not saying your use-case doesn't exist or even that it's rare,
>>> just that I don't think you can generalize from your experience here.
>>>
>>> On Thu, Aug 13, 2020 at 8:36 PM Joe Marty 
>>> wrote:
>>>
 I'm very new to Go - apologies in advance if I'm missing something:

 I find i

[go-nuts] [modules] List available only patch upgrades

[Jérôme LAFORGE]

Hello Gophers,

I want to list modules available only for available only patch upgrades.
The given example here 
https://github.com/golang/go/wiki/Modules#how-to-upgrade-and-downgrade-dependencies
 is 
for direct with minor and patch (I just want patch)

I want use this in my CI with https://github.com/psampaz/go-mod-outdated.

Many thx
Regards,
Jérôme

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4dfae07b-3701-4dee-95a9-91ef5de499b0o%40googlegroups.com.

Re: [go-nuts] where is go code generate type info?

[xie cui]

i find the reference code in cmd/compile/internal/gc/reflect.go

On Friday, August 14, 2020 at 8:52:54 PM UTC+8 Volker Dobler wrote:

> On Friday, 14 August 2020 13:00:19 UTC+2, xie cui wrote:
>>
>> the return instance of reflect.TypeOf(some object) should be generate by 
>> compiler, the type info which could be in elf files. i want to known where 
>> compiler generate it.
>>
>
> Maybe this is the reason for your confusion.
> Your assumption that the compiler creates the value returned
> by reflect.TypeOf is _plain_ _wrong_. This is _not_ done
> during compile time as it  cannot be during compile time.
> This happens during run time and thus _not_ by the compiler.
>
> You cannot know where the compiler generates it  because
> the compiler doesn't generate it.
>
> The instance which is returned by reflect.TypeOf is generated
> by package reflect in the two lines
> https://golang.org/src/reflect/type.go#L1367 and 1368.
>
> V.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5adca4b5-0110-4a32-b18a-3752fa8ab762n%40googlegroups.com.

Re: [go-nuts] map without default values

[Joe Marty]

Thanks for the insights!

Yeah, I can see how the convention of "always testing for failure" is 
better than a panic, in that it requires you to handle the possibility of a 
failure for things that may commonly fail.  In that respect though, I don't 
understand why the "comma OK" is optional.  Elm, for instance, handles 
things similarly, and has no panics or errors at all as a result because it 
enforces handling of every possible outcome.  But in Go, it seems like... 
in places where it's not easy to use "comma OK" (maybe in the middle of a 
larger expression), or if I forget, I could easily confuse the default 
result from a boolean map (false) with an actual false value!  In Python or 
Elm, or Ruby, there would be a clear distinction and/or a panic.

I agree that it's not a common case that you might want a panic - in fact I 
*never* want a panic, haha!  I suppose it's more of a question of language 
convention vs. language enforcement.  Because I'm human, and rarely write 
perfect code, I would prefer for the compiler (or the runtime environment) 
to have an error if I make a mistake like that.  And even if in 90% of 
cases, it's not a mistake and can be resolved by using a sensible default 
value, if in 10% of cases it IS a mistake, I feel like it makes more sense 
that the language should enforce handling it, while making it easy to 
specify a default for the 90% of cases where one is actually appropriate.  
In the current situation, there's no way for me to guard against mistakes 
in code maintenance.  I can intentionally panic in a particular instance, 
but if I'm maintaining the code a year later, and make a mistaken 
assumption about the existence of a key, intentionally checking and 
panicking in that case isn't really an option/solution since the definition 
of the context is that it's unintentional :D

I suppose maybe there's a way to setup a style linter to enforce a failure 
check for every map access?  (But that's a lot more tedious than just 
enabling a default where appropriate, or disabling it where it's not...)

On Thursday, August 13, 2020 at 2:11:47 PM UTC-5 Michael Jones wrote:

> Joe, your question is perfectly answered by Axel. 
>
> I'll just share a few (personal) Go "style" comments:
>
> Go likes you to test explicitly for failure where that is possible: did 
> the open fail, did the pipe break, etc.Multiple return values make this 
> clear by avoiding the need for a "reserved" error value of the normal-case 
> return.
>
> Go likes untested actions to work. In your case adding an existing key to 
> a map replaces the old entry, accessing a missing entry returns the default 
> value. ["no surprises"]
>
> Go likes you to combine these approaches to make your own more elaborate 
> behaviors using the "comma OK" approach that Axel shared. In your case, 
> adding, and deleting could complain if there is already a matching entry, 
> or not a matching entry, or -- and this is the real reason -- by looking at 
> the payload of a new or matching entry to use application logic to decide 
> if that's ok or not. Only you can know so Go won't second guess you, and 
> the test-rather-than-panic style is because testing right there is deemed 
> the right way.
>
>
> On Thu, Aug 13, 2020 at 11:42 AM 'Axel Wagner' via golang-nuts <
> golan...@googlegroups.com> wrote:
>
>> No, there isn't, but you can check if the value exists:
>>
>> x, ok := m[k]
>> if !ok {
>> panic("does not exist")
>> }
>>
>> You can also wrap that with methods, if you want to avoid the extra check.
>>
>> I disagree with you that panicking on a non-existent key is better - 
>> either in general, or in the majority of cases. Personally, I don't think I 
>> encountered many use-cases where the zero-value wasn't the perfect thing to 
>> use. I'm not saying your use-case doesn't exist or even that it's rare, 
>> just that I don't think you can generalize from your experience here.
>>
>> On Thu, Aug 13, 2020 at 8:36 PM Joe Marty  
>> wrote:
>>
>>> I'm very new to Go - apologies in advance if I'm missing something:
>>>
>>> I find it frustrating that there's no way to create a map that does 
>>> *not* automatically return a zero value for undefined key access by default.
>>>
>>> I love the fact that Go doesn't return "nil" for this use case (I love 
>>> Ruby, but I don't think they got that quite right), but returning a default 
>>> value is worse!  It would make so much more sense if it would just panic 
>>> when accessing an undefined key.  I'm not a Python guy, but I think this is 
>>> something Python got right.  
>>>
>>> Creating a map that returns some default value when you access an 
>>> undefined key should be a special kind of map, or a special argument to 
>>> initializing the map (which Ruby does allow).  In Go, is there even any way 
>>> to create a map that panics when you access an undefined key?
>>>
>>> -Joe
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "golang-nuts

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

[jake...@gmail.com]

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

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

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

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

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

[go-nuts] How to build an object file for a specific GOOS and GOARCH with external linker?

[rotusmailbox]

i'm trying to create an object file by using "go build" for GOOS=linux 
GOARCH=386.
My current go environment has GOOS=linux GOARCH=amd64.

i know that go build directly builds and links the files, but i want to link 
files using an external linker file, so i need only the object file to be 
created.

i have tried to look up ways to do so, but i could not find any solution to 
this.

The files i'm trying to compile can be .go files that have a main function or 
just a non-main-package.

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

Re: [go-nuts] where is go code generate type info?

[Mikael Gustavsson]

But those two lines don't do much, the first line reads the type pointer 
out of the interface, and the function toType is just a nil check: 
https://golang.org/src/reflect/type.go?s=38892:38923#L2963

I'm guessing xie cui is looking for where the instances of for example 
structType: https://golang.org/src/reflect/type.go?s=38892:38923#L435 are 
created and how the info for the struct fields are filled in.

On Friday, August 14, 2020 at 2:52:54 PM UTC+2, Volker Dobler wrote:
>
> On Friday, 14 August 2020 13:00:19 UTC+2, xie cui wrote:
>>
>> the return instance of reflect.TypeOf(some object) should be generate by 
>> compiler, the type info which could be in elf files. i want to known where 
>> compiler generate it.
>>
>
> Maybe this is the reason for your confusion.
> Your assumption that the compiler creates the value returned
> by reflect.TypeOf is _plain_ _wrong_. This is _not_ done
> during compile time as it  cannot be during compile time.
> This happens during run time and thus _not_ by the compiler.
>
> You cannot know where the compiler generates it  because
> the compiler doesn't generate it.
>
> The instance which is returned by reflect.TypeOf is generated
> by package reflect in the two lines
> https://golang.org/src/reflect/type.go#L1367 and 1368.
>
> V.
>

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

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

[atakanc...@gmail.com]

Hello guys, I have solved the issue.

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

Thank you both for replying.

14 Ağustos 2020 Cuma tarihinde saat 16:21:17 UTC+3 itibarıyla 
jake...@gmail.com şunları yazdı:

> This works fine for me on Windows 10. 
> What is "my.exe" doing? 
> Do you have third party antivirus software? If so, try turning it off. 
> They are notorious for causing this kind of problem. 
>
> On Friday, August 14, 2020 at 5:02:36 AM UTC-4 atakanc...@gmail.com wrote:
>
>> Hello dear fellow gophers, 
>>
>> I had a relatively simple yet quite inconvenient issue which I felt the 
>> need to ask here. In my main() function;
>>
>> os.Remove("my.exe") // err is nil, my.exe is removed
>>
>> works in Windows without any errors, but when I call exec beforehand, I 
>> get access is denied error;
>>
>> buffer, err := exec.Command("my.exe", myArgs...).Output() // err is nil 
>> here, I get desired output
>> os.Remove("my.exe") // remove "C:\\...\my.exe": Access is denied
>>
>> I tried using cmd.Process.Kill(), cmd.Process.Wait(), 
>> cmd.Start()-ioutil.ReadlAll()-cmd.Wait() alternatives as well. I kept 
>> getting no errors until 'Access is denied'. 
>>
>> I'm using go1.14 linux/amd64 for my compiler and Windows 10 Enterprise 
>> 10.0.18362.
>>
>> Thank you.
>>
>

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

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

[jake...@gmail.com]

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

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

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

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

Re: [go-nuts] where is go code generate type info?

[Volker Dobler]

On Friday, 14 August 2020 13:00:19 UTC+2, xie cui wrote:
>
> the return instance of reflect.TypeOf(some object) should be generate by 
> compiler, the type info which could be in elf files. i want to known where 
> compiler generate it.
>

Maybe this is the reason for your confusion.
Your assumption that the compiler creates the value returned
by reflect.TypeOf is _plain_ _wrong_. This is _not_ done
during compile time as it  cannot be during compile time.
This happens during run time and thus _not_ by the compiler.

You cannot know where the compiler generates it  because
the compiler doesn't generate it.

The instance which is returned by reflect.TypeOf is generated
by package reflect in the two lines
https://golang.org/src/reflect/type.go#L1367 and 1368.

V.

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

Re: [go-nuts] where is go code generate type info?

[xie cui]

i am reading gc's code. i just need to know. reflect.TypeOf return a 
interface, the interface ref to a instance or call data. that instance 
should be generate by compiler. but i can not find where is the compiler 
code that generate data about type.

On Friday, August 14, 2020 at 7:00:19 PM UTC+8 xie cui wrote:

> the return instance of reflect.TypeOf(some object) should be generate by 
> compiler, the type info which could be in elf files. i want to known where 
> compiler generate it. 
>
> On Friday, August 14, 2020 at 5:08:30 PM UTC+8 Volker Dobler wrote:
>
>> On Friday, 14 August 2020 08:15:03 UTC+2, xie cui wrote:
>>>
>>>
>>> how can i see the code genrate by compiler, and where is the compiler 
>>> code to generate these code(which file, which function). i am just curious.
>>
>>
>> Can you explain what you mean exactly by "code generated by the compiler"?
>> Are  you interested in the assembly? https://golang.org/doc/asm ?
>> The compiler sources are in
>> https://github.com/golang/go/tree/master/src/cmd/compile/internal/gc
>> and there is no single file/function which compiles package reflect.
>>
>> This really sound like a XY problem.
>>
>> V.
>>
>>  
>>
>>> On Friday, August 14, 2020 at 1:32:25 PM UTC+8 Volker Dobler wrote:
>>>
 The value returned by reflect.TypeOf is not computed during
 compile time but during run time. The code for package
 reflect is generated by the compiler during compile time
 but this is not interesting to understand reflection at all as
 it is the same code generation like for lets say net/http.

 The source code for package reflect is open source, just
 have a look. Note that https://golang.org/pkg/reflect/#TypeOf
 links directly to the source code.

 Understanding of reflection does not happen by studing
 the compiler and not the implementation of package reflect
 but by reading the appropriate blog post on blog.golang.org.

 V.


 On Friday, 14 August 2020 04:44:57 UTC+2, xie cui wrote:
>
>
> the return of reflect.TypeOf should be generate by compile, i am 
> trying to understand it, so i need to know where is code generate it in 
> compiler. i need to know compiler parts. and i am curious about what is 
> do 
> in user code also.  please tell me about it. i will be appriciated.
> On Thursday, August 13, 2020 at 10:47:28 PM UTC+8 Jan Mercl wrote:
>
>> On Thu, Aug 13, 2020 at 3:53 PM xie cui  wrote: 
>>
>> > ..., i know this type struct in generate by compiler, and i need to 
>> know where is this code, and how to generate the struct fields and 
>> methods? 
>>
>> To avoid the possibility of the XY problem, can you please tell more 
>> about the goal of "generating struct fields and methods" and what 
>> exactly is meant by that? Some things can be done by the compiler, 
>> some in user code and the two feature sets are definitely not the 
>> same. 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/74aa85e3-7eb2-472b-a51b-a780a702487cn%40googlegroups.com.

Re: [go-nuts] where is go code generate type info?

[xie cui]

the return instance of reflect.TypeOf(some object) should be generate by 
compiler, the type info which could be in elf files. i want to known where 
compiler generate it. 

On Friday, August 14, 2020 at 5:08:30 PM UTC+8 Volker Dobler wrote:

> On Friday, 14 August 2020 08:15:03 UTC+2, xie cui wrote:
>>
>>
>> how can i see the code genrate by compiler, and where is the compiler 
>> code to generate these code(which file, which function). i am just curious.
>
>
> Can you explain what you mean exactly by "code generated by the compiler"?
> Are  you interested in the assembly? https://golang.org/doc/asm ?
> The compiler sources are in
> https://github.com/golang/go/tree/master/src/cmd/compile/internal/gc
> and there is no single file/function which compiles package reflect.
>
> This really sound like a XY problem.
>
> V.
>
>  
>
>> On Friday, August 14, 2020 at 1:32:25 PM UTC+8 Volker Dobler wrote:
>>
>>> The value returned by reflect.TypeOf is not computed during
>>> compile time but during run time. The code for package
>>> reflect is generated by the compiler during compile time
>>> but this is not interesting to understand reflection at all as
>>> it is the same code generation like for lets say net/http.
>>>
>>> The source code for package reflect is open source, just
>>> have a look. Note that https://golang.org/pkg/reflect/#TypeOf
>>> links directly to the source code.
>>>
>>> Understanding of reflection does not happen by studing
>>> the compiler and not the implementation of package reflect
>>> but by reading the appropriate blog post on blog.golang.org.
>>>
>>> V.
>>>
>>>
>>> On Friday, 14 August 2020 04:44:57 UTC+2, xie cui wrote:


 the return of reflect.TypeOf should be generate by compile, i am trying 
 to understand it, so i need to know where is code generate it in compiler. 
 i need to know compiler parts. and i am curious about what is do in user 
 code also.  please tell me about it. i will be appriciated.
 On Thursday, August 13, 2020 at 10:47:28 PM UTC+8 Jan Mercl wrote:

> On Thu, Aug 13, 2020 at 3:53 PM xie cui  wrote: 
>
> > ..., i know this type struct in generate by compiler, and i need to 
> know where is this code, and how to generate the struct fields and 
> methods? 
>
> To avoid the possibility of the XY problem, can you please tell more 
> about the goal of "generating struct fields and methods" and what 
> exactly is meant by that? Some things can be done by the compiler, 
> some in user code and the two feature sets are definitely not the 
> same. 
>


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

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

[atakanc...@gmail.com]

Thank you for your reply. Unfortunately taskkill returns 128

buffer, err := exec.Command("my.exe", myArgs...).Output() // err is nil 
here, I get desired output 
_, err := exec.Command("taskkill", "/F", "/im", "my.exe").Output() // err 
is exit code 128, tried same with /pid, cmd.Process.Pid as well
os.Remove("my.exe") // remove "C:\\...\my.exe": Access is denied  

14 Ağustos 2020 Cuma tarihinde saat 12:11:56 UTC+3 itibarıyla Tamás Gulácsi 
şunları yazdı:

> Windows locks the running program's file, you cannot delete it when it's 
> running - use "taskkill /F" to kill it proper.
>
> atakanc...@gmail.com a következőt írta (2020. augusztus 14., péntek, 
> 11:02:36 UTC+2):
>
>> Hello dear fellow gophers, 
>>
>> I had a relatively simple yet quite inconvenient issue which I felt the 
>> need to ask here. In my main() function;
>>
>> os.Remove("my.exe") // err is nil, my.exe is removed
>>
>> works in Windows without any errors, but when I call exec beforehand, I 
>> get access is denied error;
>>
>> buffer, err := exec.Command("my.exe", myArgs...).Output() // err is nil 
>> here, I get desired output
>> os.Remove("my.exe") // remove "C:\\...\my.exe": Access is denied
>>
>> I tried using cmd.Process.Kill(), cmd.Process.Wait(), 
>> cmd.Start()-ioutil.ReadlAll()-cmd.Wait() alternatives as well. I kept 
>> getting no errors until 'Access is denied'. 
>>
>> I'm using go1.14 linux/amd64 for my compiler and Windows 10 Enterprise 
>> 10.0.18362.
>>
>> Thank you.
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a93e0584-9eba-4e6c-aeac-389f0b31ed88n%40googlegroups.com.

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

[roger peppe]

On Thu, 13 Aug 2020 at 23:30, Ian Lance Taylor  wrote:

> On Thu, Aug 13, 2020 at 3:09 PM roger peppe  wrote:
> >
> > I do feel that the "all or nothing" nature of type parameter lists (if
> you specify one type parameter, you must explicitly specify all of the
> others too, even if they could otherwise be inferred) is likely to get in
> the way here. I'd like to see a way to specify some type parameters and not
> others, so that constraint type inference can work even when, for example,
> there's a generic return type parameter that can't be inferred from the
> arguments. We could potentially use an underscore for that.
>
> If I understand you correctly, we changed that when we added the
> constraint type inference section.  See the updated
>
> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#type-inference
> section.
>

Ah, that's useful and interesting, thanks. I suspect that being able to
selectively omit type parameters could be useful though - for when there's
no obvious ordering to the parameters and you want to infer some of the
earlier types in the list while specifying some later ones. Maybe in
practice it'll always be possible to use an explicit type conversion in a
value parameter to do this though, especially if Steven
Blenkinsop's ordering suggestions are followed (perhaps that could be a `go
vet` checki).

  cheers,
rog.

> 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/CAJhgacjPfoUp%2Bkhb4csuF%2Bz%3DTEWchZuSri94yTP4%2BtRvtnK5Ng%40mail.gmail.com.

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

[Tamás Gulácsi]

Windows locks the running program's file, you cannot delete it when it's 
running - use "taskkill /F" to kill it proper.

atakanc...@gmail.com a következőt írta (2020. augusztus 14., péntek, 
11:02:36 UTC+2):

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

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

Re: [go-nuts] where is go code generate type info?

[Volker Dobler]

On Friday, 14 August 2020 08:15:03 UTC+2, xie cui wrote:
>
>
> how can i see the code genrate by compiler, and where is the compiler code 
> to generate these code(which file, which function). i am just curious.


Can you explain what you mean exactly by "code generated by the compiler"?
Are  you interested in the assembly? https://golang.org/doc/asm ?
The compiler sources are in
https://github.com/golang/go/tree/master/src/cmd/compile/internal/gc
and there is no single file/function which compiles package reflect.

This really sound like a XY problem.

V.

 

> On Friday, August 14, 2020 at 1:32:25 PM UTC+8 Volker Dobler wrote:
>
>> The value returned by reflect.TypeOf is not computed during
>> compile time but during run time. The code for package
>> reflect is generated by the compiler during compile time
>> but this is not interesting to understand reflection at all as
>> it is the same code generation like for lets say net/http.
>>
>> The source code for package reflect is open source, just
>> have a look. Note that https://golang.org/pkg/reflect/#TypeOf
>> links directly to the source code.
>>
>> Understanding of reflection does not happen by studing
>> the compiler and not the implementation of package reflect
>> but by reading the appropriate blog post on blog.golang.org.
>>
>> V.
>>
>>
>> On Friday, 14 August 2020 04:44:57 UTC+2, xie cui wrote:
>>>
>>>
>>> the return of reflect.TypeOf should be generate by compile, i am trying 
>>> to understand it, so i need to know where is code generate it in compiler. 
>>> i need to know compiler parts. and i am curious about what is do in user 
>>> code also.  please tell me about it. i will be appriciated.
>>> On Thursday, August 13, 2020 at 10:47:28 PM UTC+8 Jan Mercl wrote:
>>>
 On Thu, Aug 13, 2020 at 3:53 PM xie cui  wrote: 

 > ..., i know this type struct in generate by compiler, and i need to 
 know where is this code, and how to generate the struct fields and 
 methods? 

 To avoid the possibility of the XY problem, can you please tell more 
 about the goal of "generating struct fields and methods" and what 
 exactly is meant by that? Some things can be done by the compiler, 
 some in user code and the two feature sets are definitely not the 
 same. 

>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/61c04019-e7e2-49e4-998c-f87737e54ad8o%40googlegroups.com.

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

[Atakan Çolak]

Hello dear fellow gophers, 

I had a relatively simple yet quite inconvenient issue which I felt the 
need to ask here. In my main() function;

os.Remove("my.exe") // err is nil, my.exe is removed

works in Windows without any errors, but when I call exec beforehand, I get 
access is denied error;

buffer, err := exec.Command("my.exe", myArgs...).Output() // err is nil 
here, I get desired output
os.Remove("my.exe") // remove "C:\\...\my.exe": Access is denied

I tried using cmd.Process.Kill(), cmd.Process.Wait(), 
cmd.Start()-ioutil.ReadlAll()-cmd.Wait() alternatives as well. I kept 
getting no errors until 'Access is denied'. 

I'm using go1.14 linux/amd64 for my compiler and Windows 10 Enterprise 
10.0.18362.

Thank you.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6b88ac39-f0a1-4eee-92d1-e63d8b55261do%40googlegroups.com.