попробуй новую переменную объявить

пробовал, не помогает

пробовал, не помогает

ну так ты закрываешь канал после отправки

в тот же канал уже не отправить

то есть создается другой

Register два раза вызывается?

нет

да, я воспроизвел

щас разберемся

Ура!) я бы просто переписал на waitGroup, но хочется понять, в чем тут нюанс

https://play.golang.org/p/5B6xzV2r1b7

да, тут как раз тоже есть такая беда

https://play.golang.org/p/TcWwQkiWLbr

break зарулил, дело в for

у меня один вопрос - как он читает из закрытого канала и закрывает его еще раз?))))

https://play.golang.org/p/TcWwQkiWLbr

ну если делать так, как тут, то не удастся дождаться данных из канала sectorCh

у меня один вопрос - как он читает из закрытого канала и закрывает его еще раз?))))

у меня ровно тот же вопрос =)

не, читать то из закрытого канала в принципе вроде ведь можно? во всяком случае через for range точно можно из него все достать

но откуда в канале берется инфа, после того как он закрывается - загадка

у меня внутри кейса, который читает канал юзера стреляет дважды

кажется в селекте нужно сделать типа того: case u, ok = <-userCh: if !ok { break // return }

при закрытии канала оно еще что-то пуляет емнип

кажется в селекте нужно сделать типа того: case u, ok = <-userCh: if !ok { break // return }

да, это наверняка поможет, но это не костыль?

это ожидаемое поведение

но откуда в канале берется инфа, после того как он закрывается - загадка

A receive from a closed channel returns the zero value immediately

кажется в селекте нужно сделать типа того: case u, ok = <-userCh: if !ok { break // return }

точно https://play.golang.org/p/OFgSlSwH6wC

https://dave.cheney.net/2014/03/19/channel-axioms

во дела не знал

это ожидаемое поведение

спасибо большое, просвятил

буду знать)

https://play.golang.org/p/FfeL-lVIibl

надо ok проверять

A receive from a closed channel returns the zero value immediately

т.е. селект всегда будет пробиваться пустыми значениями из закрытых каналов?

иначе читаем из пустого канала

т.е. селект всегда будет пробиваться пустыми значениями из закрытых каналов?

имнип не всегда, 1 раз

имнип не всегда, 1 раз

в моей демке всегда

в моей демке всегда

у меня тоже

даже после вычитывания пустого значения

т.е. селект всегда будет пробиваться пустыми значениями из закрытых каналов?

да, потому что select делает неблокирующее чтение и в переменную слева всегда что то должно упасть

имнип не всегда, 1 раз

https://play.golang.org/p/c0Ho8dw0Lg7

т.е. селект всегда будет пробиваться пустыми значениями из закрытых каналов?

да, см https://dave.cheney.net/2014/03/19/channel-axioms

Б-же, у нас что, люди каналы уже не знают?

Б-же, у нас что, люди каналы уже не знают?

не все 10 лет на гошечке сидят

Б-же, у нас что, люди каналы уже не знают?

эко тебя отнейросетило :) конечно не знают

в моей демке всегда

сори, всегда думал что раз.

не все 10 лет на гошечке сидят

Я тоже на алефе не писал, и чо?

эко тебя отнейросетило :) конечно не знают

А? Первую фразу переведи, плиз 😂

https://geeksus.ru/wp-content/uploads/2017/10/13.jpg

А? Первую фразу переведи, плиз 😂

ну, на аватарке у тебя фото обработанное призмой

ну, на аватарке у тебя фото обработанное призмой

А, ты об этом

Это не призма

Привет!

Можете подсказать по локализации?

i18n.MustLoadTranslationFile("en-us.all.json") T, _ := i18n.Tfunc("en-US") t, _ := template.ParseFiles("template/index.html", "template/header.html", "template/footer.html") t.Funcs(map[string]interface{}{ "T": T,}) t.Execute(w, map[string]interface{}{"Title": "New cat"}) правильно ли я делаю?

в шаблоне <h1>{{T "home_button" .}}</h1> но вываливается ошибка в консоль runtime error: invalid memory address or nil pointer dereference goroutine

https://gobyexample.com/select

а чем вот этот пример принципиально отличается от моего?

https://gobyexample.com/select

тем, что каналы не закрываются

2 поменяй на 3, закрой каналы, и будет всегда первый case выполняться

Это не призма

https://github.com/fogleman/primitive оно чтоли?

Привет, я тут подумал. Думаю, надо сделать петицию против использования int.

тем, что каналы не закрываются

да, верно, спасибо!

Привет, я тут подумал. Думаю, надо сделать петицию против использования int.

чому?

Ненавижу, то он int32, то он int64. А причин, почему он лучше int64 и int32 не вижу. Возможно, что то на уровне ассемблера.

Ненавижу, то он int32, то он int64. А причин, почему он лучше int64 и int32 не вижу. Возможно, что то на уровне ассемблера.

че рили? всегда думал что только 32

Ненавижу, то он int32, то он int64. А причин, почему он лучше int64 и int32 не вижу. Возможно, что то на уровне ассемблера.

это untyped int, он является 32 или 64 в зависимости от архитектуры

боже( нужно внимательнее читать комментарии. Увидел циферки 32 и такой запомнил

int is a signed integer type that is at least 32 bits in size. It is a distinct type, however, and not an alias for, say, int32.

это untyped int, он является 32 или 64 в зависимости от архитектуры

Угу

это untyped int, он является 32 или 64 в зависимости от архитектуры

Понял ваш мэсседж, неправильно выразился

Привет, я тут подумал. Думаю, надо сделать петицию против использования int.

вы к нам из каких краев?

в смысле языков

да вроде он всегда тут был

вы к нам из каких краев?

На го больше года уже пишу. Просто достало, когда одна библиотека тебе присылает int64, а второй ты должен отослать int.

И нужно переводить типы. А best practice нет

Накипео

эм, а если в int32 переводить, то лучше?

эм, а если в int32 переводить, то лучше?

Обычно вместо int пишут int64, а не 32.

Мало либ, где int32 будет дефолтным интом

либы есть и они разные, int/uint тоже отменить?