Re: [go-nuts] evaluation of range expression in for-range loop

[Tamás Gulácsi]

Yes.
If you manipulate the meaning of the index (i) or the length of the slice, 
then do it explicitly:

for i := 0; i < len(a); i++ {
  if a[i] == 0 { //delete
a[i]=a[0]
a = a[1:]
i--
  }
}

For other methods, see 
https://go.dev/wiki/SliceTricks#filtering-without-allocating

Shivansh Rustagi a következőt írta (2024. február 5., hétfő, 15:29:06 
UTC+1):

> Hi Guys, I had a question regarding:
>
> > On the other hand, if you have `for i, v := range a {` then the
> > expression *is* evaluated before the start of the loop.
>
> I have a code (https://goplay.tools/snippet/dMwD0_rEhkB) where I am 
> ranging over a slice, and updating (removing the zeroth element form the 
> same slice being ranged over) here I see that the "i" values is not being 
> re-evaluated, it just gives an increasing number even if the ranged over 
> slice has changed . Which can also be seen when I am printing the ith 
> element given to me by the range, and the receiving out of range panic
>
> On Saturday, March 19, 2022 at 2:01:27 AM UTC+5:30 Dan Kortschak wrote:
>
>> On Fri, 2022-03-18 at 16:53 +0100, 'Axel Wagner' via golang-nuts wrote: 
>> > One thing to keep in mind is that Go development was incremental and 
>> > was done, from early on, by having multiple implementations. 
>> > Incremental processes often lead to different results than designing 
>> > a language from a blank slate. Ambiguities in the spec are often 
>> > discovered only when someone notices that implementations disagree 
>> > and must be resolved somehow. Sometimes that happens after Go 1 and 
>> > the resolution must happen in a way that, as much as possible, 
>> > retains stability guarantees. So, it's not unsurprising if we get 
>> > non-obvious spec clauses such as this. 
>> > 
>> > Specifically, I can well imagine that this particular case arose, 
>> > because it was discovered after the fact that one implementation 
>> > contained an optimization to not evaluate the argument to `len`, 
>> > while the other didn't and the question of side-effects only arose 
>> > when someone noticed. 
>> > 
>> > I don't really know the answer to your question. I can't think of 
>> > anything which would break. That being said, I also don't think it's 
>> > something that really needs "fixing", as it seems a pretty uncommon 
>> > concern. 
>>
>> There is some discussion on the reasons when the original narrowing of 
>> the behaviour was introduced (https://codereview.appspot.com/050). 
>>
>> It's actually quite an interesting spec change from a language history 
>> perspective, more because of the chan discussion than this particular 
>> issue. 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/237f0947-82e3-4467-834c-3c5fbfbb698dn%40googlegroups.com.

[go-nuts] Re: go mod download fails on docker for 1.20 (but not for 1.18)

['Bryan C. Mills' via golang-nuts]

In https://go.dev/issue/52545 we saw failures in the cmd/go tests on Google 
Cloud VMs due to a combination of a small number of available NAT ports and 
port exhaustion from TIME_WAIT connections, but the failure mode there was 
different (timed-out git commands rather than "cannot assign requested 
address").

If the problem is the total number of open connections, rather than 
connections in the TIME_WAIT state, you could try setting 
`GODEBUG=cmdgonetlimit=4` or similar in your environment, although I don't 
think that will prevent the accumulation of idle connections. It would 
probably be helpful to figure out exactly how many connections you have 
open (and what state they're in) when the error occurs.

(When I was investigating #52545 I wrote a little `ss` wrapper to monitor 
connection states; 
see https://github.com/bcmills/cmd/blob/main/watchnet/main.go.)



On Friday, February 2, 2024 at 1:13:11 PM UTC-5 TheDiveO wrote:

> carrier-grade NAT?
>
> On Friday, February 2, 2024 at 7:05:42 PM UTC+1 sprynger wrote:
>
>> In my case it might be an ISP problem, since this only happens to me when 
>> I work from home. At work, the exact same project builds all at once 
>> without any issues.
>>
>> A quinta-feira, 1 de fevereiro de 2024 à(s) 21:07:03 UTC, TheDiveO 
>> escreveu:
>>
>>> Are you still using Debian 11 and the outdated Debian docker.io package 
>>> with Docker 18? What happens when you use a recent Docker, either 24.x or 
>>> hot-off-the-press 25.0.1? And then build using a Go-Alpine base image? Do 
>>> you still use Debian's broken Docker seccomp profile...?
>>>
>>> I'm on an IPv6 uplink and in all these years never seen this issue. I'm 
>>> not using Debian due to its totally outdated cloud/container packages, but 
>>> instead a *ubuntu host with docker-ce packages, using alpine base images 
>>> for building ... and never such an issue. So my bet would be on Debian 
>>> and/or your ISP. From my bad experience with many nightmarish late hour 
>>> diagnosis sessions with oversees my bet is on Debian, especially the LTS 
>>> long-term-broken variants.
>>>
>>> On Thursday, February 1, 2024 at 8:48:42 PM UTC+1 Sebastiaan van der 
>>> Meulen wrote:
>>>
 Same issue here without solution. Hoping anyone finds one

 Op zondag 14 januari 2024 om 22:53:54 UTC+1 schreef Dmitry Anderson 
 (4nd3rs0n):

> I'm having the same problem. For now I just vendor modules to a 
> project modules and run without installing anything from the container, 
> but 
> also would like to find a fix.
> On Monday, May 22, 2023 at 2:29:08 AM UTC+2 Joao Miguel Ferreira wrote:
>
>> Hello all,
>>
>> My docker build is ok with FROM golang:1.18-alpine, FROM 
>> golang:1.18-buster and FROM golang:1.18-bullseye images. The 
>> application works. All is fine on the 3 cases.
>>
>> But the docker build fails with FROM golang:1.20-alpine, FROM 
>> golang:1.20-buster and FROM golang:1.20-bullseye images.
>>
>> This is the error message I get:
>>
>> go: github.com/davecgh/go-...@v1.1.1 
>> : Get "
>> https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": 
>> dial tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign 
>> requested 
>> address
>>
>> It happens during go mod download. It happens when building on 
>> Debian11, Debian12 and Ubuntu22 hosts.
>>
>> I have tried many things including going inside the container and 
>> downloading the module with wget. It works fine. Maybe something changed 
>> from 1.18 to 1.20 related to ipv6.
>>
>> I would like to be able to do the build with one golang 1.20 image. 
>> But I can not understand what is wrong. Can you help clarify that error 
>> and 
>> how to overcome it?
>>
>>
>>

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

Re: [go-nuts] evaluation of range expression in for-range loop

[Shivansh Rustagi]

Hi Guys, I had a question regarding:

> On the other hand, if you have `for i, v := range a {` then the
> expression *is* evaluated before the start of the loop.

I have a code (https://goplay.tools/snippet/dMwD0_rEhkB) where I am ranging 
over a slice, and updating (removing the zeroth element form the same slice 
being ranged over) here I see that the "i" values is not being 
re-evaluated, it just gives an increasing number even if the ranged over 
slice has changed . Which can also be seen when I am printing the ith 
element given to me by the range, and the receiving out of range panic

On Saturday, March 19, 2022 at 2:01:27 AM UTC+5:30 Dan Kortschak wrote:

> On Fri, 2022-03-18 at 16:53 +0100, 'Axel Wagner' via golang-nuts wrote:
> > One thing to keep in mind is that Go development was incremental and
> > was done, from early on, by having multiple implementations.
> > Incremental processes often lead to different results than designing
> > a language from a blank slate. Ambiguities in the spec are often
> > discovered only when someone notices that implementations disagree
> > and must be resolved somehow. Sometimes that happens after Go 1 and
> > the resolution must happen in a way that, as much as possible,
> > retains stability guarantees. So, it's not unsurprising if we get
> > non-obvious spec clauses such as this.
> >
> > Specifically, I can well imagine that this particular case arose,
> > because it was discovered after the fact that one implementation
> > contained an optimization to not evaluate the argument to `len`,
> > while the other didn't and the question of side-effects only arose
> > when someone noticed.
> >
> > I don't really know the answer to your question. I can't think of
> > anything which would break. That being said, I also don't think it's
> > something that really needs "fixing", as it seems a pretty uncommon
> > concern.
>
> There is some discussion on the reasons when the original narrowing of
> the behaviour was introduced (https://codereview.appspot.com/050).
>
> It's actually quite an interesting spec change from a language history
> perspective, more because of the chan discussion than this particular
> issue.
>
>
>

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