Re: [go-nuts] Re: module confusion

[fgergo]

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

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

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

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

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

[seank...@gmail.com]

that's an invalid semver, no leading 0s  allowed

https://semver.org/#spec-item-2 :
A normal version number MUST take the form X.Y.Z where X, Y, and Z are 
non-negative integers, and MUST NOT contain leading zeroes. X is the major 
version, Y is the minor version, and Z is the patch version. Each element 
MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

On Saturday, August 15, 2020 at 4:08:06 AM UTC+2 sunto...@gmail.com wrote:

> 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/eas...@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/074b1e7d-7b1c-43c0-abc6-d20eb2625c7dn%40googlegroups.com.

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

[roger peppe]

On Sat, 15 Aug 2020 at 04:57, Patrick Smith  wrote:

> 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


I think that works pretty well, and seems to be the direction that things
are going in.
Here's your example cleaned up a bit to show just that latest example, and
also
showing how it looks when adapting a built-in type:

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

It's possible to build a generic adaptor type from the value-style
interface to the pointer-style interface, which you might find interesting:

  https://go2goplay.golang.org/p/NiQY_-kWvu8

This could *almost* work on image.Point, except that Point.Mul has the
wrong signature.

  cheers,
rog.

>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send 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
> .
>

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

[go-nuts] which pass of SSA will transform a ssa.Value(op=OpPhi) phi operations to a normal(not phi operations)?

[xie cui]

as we know, SSA has phi function, but the output of go tool compile -S 
xxx.go which do not contains a phi instruction. so i am trying to find out 
which SSA pass will transform a phi Op ssa.Value to normal ops?

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

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

[Tong Sun]

Oh, thanks.

The very reason that I do that is to avoid the following situation:

for i in `jot 12`; do echo $i > f; git commit -am "$i"; git tag v0.0.$i; done

$ git tag -l
v0.0.1
v0.0.10
v0.0.11
v0.0.12
v0.0.2
v0.0.3
v0.0.4
v0.0.5
v0.0.6
v0.0.7
v0.0.8
v0.0.9

If no leading 0s allowed, how do you guys solve the above problem?


On Sat, Aug 15, 2020 at 5:01 AM seank...@gmail.com  wrote:
>
> that's an invalid semver, no leading 0s  allowed
>
> https://semver.org/#spec-item-2 :
> A normal version number MUST take the form X.Y.Z where X, Y, and Z are 
> non-negative integers, and MUST NOT contain leading zeroes. X is the major 
> version, Y is the minor version, and Z is the patch version. Each element 
> MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
>
> On Saturday, August 15, 2020 at 4:08:06 AM UTC+2 sunto...@gmail.com wrote:
>>
>> 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/eas...@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 a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/ECa7ZlbLNW0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/074b1e7d-7b1c-43c0-abc6-d20eb2625c7dn%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/CAMmz1OdXGXc5D86oMdC2ABZ%2BuSER_P8hb7piimNPac3enihjeA%40mail.gmail.com.

Re: [go-nuts] map without default values

[jake...@gmail.com]

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

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

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

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

[Lutz Horn]

Take a look at this: https://gist.github.com/loisaidasam/b1e6879f3deb495c22cc

Von: Tong Sun
Gesendet: ‎15.‎08.‎2020 17:51
An: golang-nuts
Cc: seank...@gmail.com
Betreff: Re: [go-nuts] Re: The latest version of package in pkg.go.dev

Oh, thanks.

The very reason that I do that is to avoid the following situation:

for i in `jot 12`; do echo $i > f; git commit -am "$i"; git tag v0.0.$i; done

$ git tag -l
v0.0.1
v0.0.10
v0.0.11
v0.0.12
v0.0.2
v0.0.3
v0.0.4
v0.0.5
v0.0.6
v0.0.7
v0.0.8
v0.0.9

If no leading 0s allowed, how do you guys solve the above problem?


On Sat, Aug 15, 2020 at 5:01 AM seank...@gmail.com  wrote:
>
> that's an invalid semver, no leading 0s  allowed
>
> https://semver.org/#spec-item-2 :
> A normal version number MUST take the form X.Y.Z where X, Y, and Z are 
> non-negative integers, and MUST NOT contain leading zeroes. X is the major 
> version, Y is the minor version, and Z is the patch version. Each element 
> MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
>
> On Saturday, August 15, 2020 at 4:08:06 AM UTC+2 sunto...@gmail.com wrote:
>>
>> 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/eas...@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 a topic in the Google 
> Groups "golang-nuts" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/golang-nuts/ECa7ZlbLNW0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/074b1e7d-7b1c-43c0-abc6-d20eb2625c7dn%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/CAMmz1OdXGXc5D86oMdC2ABZ%2BuSER_P8hb7piimNPac3enihjeA%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/AM7P191MB10609EBB105DD66872F626429E410%40AM7P191MB1060.EURP191.PROD.OUTLOOK.COM.

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

[Shulhan]

> On 15 Aug 2020, at 22.50, Tong Sun  wrote:
> 
> Oh, thanks.
> 
> The very reason that I do that is to avoid the following situation:
> 
> for i in `jot 12`; do echo $i > f; git commit -am "$i"; git tag v0.0.$i; done
> 
> $ git tag -l
> v0.0.1
> v0.0.10
> v0.0.11
> v0.0.12
> v0.0.2
> v0.0.3
> v0.0.4
> v0.0.5
> v0.0.6
> v0.0.7
> v0.0.8
> v0.0.9
> 
> If no leading 0s allowed, how do you guys solve the above problem?
> 

$ git tag -l | sort -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/DCD2A51E-F7AC-473C-863D-BFED17F0DAC5%40gmail.com.

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

[Bob Alexander]

Here's what I think is really going on:

At the end of a process's execution, 2 things happen:
  - The process's code finishes its execution -- wait returns.
  - The OS closes the executable file.

The second item always "comes after" the first. On Windows the delay might 
be a few milliseconds, which can cause a problem, since an attempt to 
delete the executable right after wait returns can fail because the 
executable is still open. On Unix, this is not a problem because it's OK to 
"remove" an open file -- the file doesn't actually get deleted until all 
openers have closed the file.

At one time, Go's os/exec for Windows had a built-in unconditional 5ms 
delay to prevent this from happening. Not sure if it still does that.

It seems that, on Windows, if a program wants to delete the executable 
right after its process has finished, if should put the delete in a little 
retry loop:
   loop a few times (10?)
  try do delete the executable
  if the delete succeeds
  exit this loop
  wait a short time (1 ms ?)
   announce an error -- executable could not be deleted in reasonable time 
after process completion

This retry loop would be the responsibility of any Windows program that 
wants to delete the executable file after its execution finishes.
In reality, this is not done in very many places, done only by some tools 
like "go run" (build, run, delete), and the occasional user-written tool. 
The vast majority of places where external processes are run leave the 
executable file alone after process completion.

Is it the responsibility of an OS like Windows the guarantee the the 
executable is closed when a process wait returns? I would say not, because 
that might cause a (small) delay in the vast majority of external process 
executions where the executable is not deleted immediately after.


On Friday, August 14, 2020 at 8:55:55 AM UTC-7, jake...@gmail.com wrote:
>
> > 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/f0a33b3f-a342-4a9a-9ccc-b0265bd2d60ao%40googlegroups.com.

[go-nuts] New linker

[Amnon]

What is the best place to read about the ongoing work on the new linker?
With the Go 1.15 release, how far along are we with the plans?
What has been achieved?
And what is still to come?

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

[go-nuts] obtaining the original type from a named alias type with go/types?

['Dan Kortschak' via golang-nuts]

I would like to be able to obtain the original type for an alias given
a source input. I can see in "go/types" that it's possible to know
whether a named type is an alias by `typ.Obj().IsAlias()`, but I cannot
see how to obtain the actual original type unless it is an alias for a
basic type.

Can someone point me to a way to get this information? From the source
it looks something like `typ.Obj().Type().(*types.Named).Obj().Type()`.
Is this correct assuming that the original type is a named type?

thanks
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/163019fbad545cd7f97d6c85fc2445bee5b1d9c7.camel%40kortschak.io.

[go-nuts] Re: which pass of SSA will transform a ssa.Value(op=OpPhi) phi operations to a normal(not phi operations)?

[Keith Randall]

The regalloc pass does that. It ensures that all the inputs and the output 
of a phi are all in the same register (or memory location), so the phi 
becomes a no-op.
The regalloc pass doesn't actually remove the phi, though. Removal is 
actually in genssa in cmd/compile/internal/gc/ssa.go. Look for 
CheckLoweredPhi, which makes sure that the above statement is actually 
correct for all phis.

On Saturday, August 15, 2020 at 7:07:23 AM UTC-7 cuiw...@gmail.com wrote:

> as we know, SSA has phi function, but the output of go tool compile -S 
> xxx.go which do not contains a phi instruction. so i am trying to find out 
> which SSA pass will transform a phi Op ssa.Value to normal ops?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/8eff0371-0e18-49ab-a8bb-e45fdf45926dn%40googlegroups.com.

Re: [go-nuts] Re: module confusion

[Marvin Renich]

* fge...@gmail.com  [200815 03:44]:
> On 8/15/20, Marvin Renich  wrote:
> > * Volker Dobler  [200814 14:53]:
> >> On Friday, 14 August 2020 20:39:37 UTC+2, K Richard Pixley wrote:
> >> > Isn't this the default location?  I just untarred the distribution...
> >>
> >> No. There is a reason https://golang.org/doc/install#install
> >> states to do  tar -C /usr/local -xzf go$VERSION.$OS-$ARCH.tar.gz
> >
> 
> > It also might be productive to mention that many (Linux?) distributions
> > (e.g. Debian, Fedora, RHEL) provide reasonably up-to-date packages for
> > Go, and that using the distribution's package manager may be easier,
> > provide better security support, and integrate better than manually
> > installing the official Go binary distribution.
> 
> Could you please give an example to "better security support" in a
> distribution's package manager?

The user can let the package manager automatically update packages with
security fixes (at least in Debian) so the user doesn't have to stay on
top of when a security update is available and manually reinstall the
updated version of Go.  (Think of trying to do this individually for
every piece of software installed on your system.)

Perhaps "simpler" would have been a better word than "better".  One of
the big reasons to use packages from a distribution rather than
installing each one from source or from upstream's binary packages is to
simplify system maintenance.

...Marvin

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

Re: [go-nuts] obtaining the original type from a named alias type with go/types?

[Ian Lance Taylor]

On Sat, Aug 15, 2020 at 3:45 PM 'Dan Kortschak' via golang-nuts
 wrote:
>
> I would like to be able to obtain the original type for an alias given
> a source input. I can see in "go/types" that it's possible to know
> whether a named type is an alias by `typ.Obj().IsAlias()`, but I cannot
> see how to obtain the actual original type unless it is an alias for a
> basic type.
>
> Can someone point me to a way to get this information? From the source
> it looks something like `typ.Obj().Type().(*types.Named).Obj().Type()`.
> Is this correct assuming that the original type is a named type?

I haven't tested it but I *think* you can just write typ.Underlying().

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/CAOyqgcWK5VcOvHm%3DuZ0vHWw7_NCkGK4km2YrwBMTs2LY5d1VfQ%40mail.gmail.com.

Re: [go-nuts] New linker

[Ian Lance Taylor]

On Sat, Aug 15, 2020 at 11:49 AM Amnon  wrote:
>
> What is the best place to read about the ongoing work on the new linker?
> With the Go 1.15 release, how far along are we with the plans?
> What has been achieved?
> And what is still to come?

The work on the new linker is close to complete and has been merged
into tip for the future 1.16 release (although 1.16 won't be released
until next February).  The work is as described at
https://golang.org/s/better-linker.

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

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

[Ian Lance Taylor]

On Fri, Aug 14, 2020 at 9:31 PM Patrick Smith  wrote:
>
> 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.

This suggestion is a little bit like the pointer methods we had in an
earlier version of the design draft
(https://go.googlesource.com/proposal/+/572fea69936c3f25a99860fce22aeb23a3263ca3/design/go2draft-type-parameters.md#pointer-methods).

I'm not sure how that would work if such an interface type were used
other than as a type constraint (of course we could forbid that case).
An interface currently holds either a pointer or a value.  If the
interface says that the method must be on the pointer type, then
presumably the interface will hold a value.  But then what address do
we take to call the method?  Taking the address of the value stored
inside the interface would mean that an interface was a reference type
rather than a value type.  I think that would be a subtle distinction
that might increase confusion when using the language.  Though
admittedly the points in this area are already rather subtle (e.g.,
the FAQ answer https://golang.org/doc/faq#pointer_to_interface).

That side, at the moment I think that the constraint type inference
idea is more versatile, as it works for types other than pointers.

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/CAOyqgcWxTFPM_fmL%3DyE9VNgob1_UZYufyz94F%3D5rov1YcJU72Q%40mail.gmail.com.

Re: [go-nuts] New linker

[Amnon]

Thanks for the answer!

Thanks also for your blog post on linkers 
https://www.airs.com/blog/archives/38
I know it is from 12 years ago. But I am behind on my reading, and it is 
taking 
me some time to catch up. And it still is an excellent introduction to what 
linkers do.

Yes Austin Clement's better-linker document is great. But it is nearly a 
year old.
So I was wondering if there were any changes to plan, surprises or new 
insights.

Austin's doc refers to your idea of a new object format for the 21st 
century. 
Has anyone developed that?

As someone who has been writing linkers since 1988, (most famously the Gold 
linker), and who has a fair 
number of commits on the dev.linker branch,  do you have any insights into 
the new linker project
which would be interesting to share with the world?

The new linker is probably the biggest change in 1.15. But there is 
surprisingly little information about it.
It is almost invisible - which I suppose is a tribute to its success.
But are there any talks about the new linker which are worth watching?

- Amnon



On Sunday, 16 August 2020 05:46:53 UTC+1, Ian Lance Taylor wrote:
>
> On Sat, Aug 15, 2020 at 11:49 AM Amnon > 
> wrote: 
> > 
> > What is the best place to read about the ongoing work on the new linker? 
> > With the Go 1.15 release, how far along are we with the plans? 
> > What has been achieved? 
> > And what is still to come? 
>
> The work on the new linker is close to complete and has been merged 
> into tip for the future 1.16 release (although 1.16 won't be released 
> until next February).  The work is as described at 
> https://golang.org/s/better-linker. 
>
> 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/68ebe380-90ec-4eea-8137-164d87fe0c7ao%40googlegroups.com.