[last news] Go 1.7.1 Released

Сам с утра обнаружил, когда вздумал обновить ГО с 1.6.х.

кто подскажет по каналам в го? https://github.com/Gasoid/bugzilla_report/blob/master/report.go#L171

все работает хорошо если 2 воркера делаю

если 3 например, то зависает

конечно я там сейчас поменял на 10 потоков, чтобы понять. но гы может кто знает в чем причина)

кто подскажет по каналам в го? https://github.com/Gasoid/bugzilla_report/blob/master/report.go#L171

У вас там взаимная блокировка. Воркеры толкают данные в done, а читать их некому, так как так как текущий поток занят толканием данных в jobs. Создавайте отдельную гоурутину для чтения данных из канала done, при том вы должны её запустить до того как начнете помещать данные в jobs.

ааа

понял

короче воркер нужен который будет читать

Совершенно верно.

мдас, походу не до конца понял как реализовать)) теперь выполняет только заданное кол-во потоков изначально, но не все джобы вопрос почему в примере нету такой блокировки? https://play.golang.org/p/y12QxBsKtT

В этом примере тоже могла бы случиться блокировка, т.к. из канала results никто не читает, пока всё не отослано в канал jobs.

Вот пример https://play.golang.org/p/q0oCNUq3OU

Если сделать джобов побольше (100), а каналы поменьше (10).

мдас, походу не до конца понял как реализовать)) теперь выполняет только заданное кол-во потоков изначально, но не все джобы вопрос почему в примере нету такой блокировки? https://play.golang.org/p/y12QxBsKtT

Потому что здесь буферезированный канал. НО все равно так лучше не делать.

Ага, и я объяснил, почему так лучше не делать — буфера может не хватить.

Чтение из results нужно запустить отдельной горутиной до записи в jobs.

Чтение из results нужно запустить отдельной горутиной до записи в jobs.

Да я уже это писал это выше. )

ну да сделал, https://github.com/Gasoid/bugzilla_report/blob/master/report.go#L170

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

Я вообще не понял что вы сделали. горутина у вас пустая. В принципе нужно было обернуть код, который у вас извлекал данные из результирующего канала, горутиной. И переместить выше запихивания данных в джоб. Так же создать один канал для ожинания окончания получения данных из результирующего канала.

о теперь яснее

похоже с каналами никак не пойму)

https://github.com/Gasoid/bugzilla_report/blob/master/report.go#L151

похоже с каналами никак не пойму)

https://play.golang.org/p/g-cjgSwqrz

Вообще вот неплохое разжевывание материала https://blog.golang.org/pipelines

о спс)) теперь норм

Кто-то смотрел "net/textpoto"? Зачем оно?

для базовой поддержки текстовых протоколов

https://groups.google.com/forum/m/#!topic/golang-ru/skJaXfAsxs8

Ребята, можно поделиться ссылкой на моего опенсорц-go-powered бота, чтобы его потестили? Вы же не против? https://telegram.me/DokkyBot

Он content в виде картинки показывает?

Ага.

Прикольно

да вот не получается туда это пронести, блин. придется на уровне кастомного пакета это все делать.

Да

Поллбот так и не умеет инлайн кнопок?

Мдауж

Хотя это имеет определенный смысл

Зачем он нужен, когда есть @vote

Зачем он нужен, когда есть @vote

Pollbot не нужен

Да

/2

[last news] Persistent cookies in GO

[last news] Pr0n Android app written in Go

ахаха

нормально ))

посмотрел видосик про то как стоило бы хэндлить ошибки в go. Не могу избавиться от ощущения костыльности: ощущение, что переизобретают исключения...надо обрабатывать один раз, стектрейс, в чем отличие от исключений? https://youtu.be/lsBF58Q-DnY

от ошибок в го двоякое ощущение

с исключениями беда что люди их просто выше пробрасывают

и забывают что нужно сделать с ними

и если вдруг в исключении есть какая-то логика

а не просто логирование то со всем этим тяжко жить

с ошибками - ты явно видишь где произошла ошибка и каков контекст

мне такой подход кажется бодее правильным

https://danluu.com/postmortem-lessons/

просто в го это через чур явно сделано:)

довольно таки часто мы пишем код в котором при ошибке нам нужно вернуть ее

и ничего не делать

если тебе интересно, можешь глянуть как в хаскеле сделаны Maybe/Either монады

не надо писать if err на каждом шагу

но если нужно обработать ошибку

ты рядом пишешь обработку, именно в той строке в которой она возникнуть может

Я не о ошибках вообще, а о этом докладе. Просто идеология "прокидывай на верх и обрататывай один раз" - как раз идеология исключений. И посему - у меня ощущение костыльности. Ибо не вижу разницы с исключениями при таком подходе.

я понял, я доклад не смотрел

ты рядом пишешь обработку, именно в той строке в которой она возникнуть может

Забыл как ответ сделать ?

Ты уже ответил и запорол мой указатель ????

все, я понял

я думал ты там или фак или петлю поставил

и не могу понять:)

Ой реально ?, а хотел ???? получился наглый указатель

Один раз обработать это хорошо. А то по десять раз на одну ошибку IFов писать приходится. Надо глянуть в живую на подход. А ошибку все равно обрабатывать придется. Под исключением она просто может затеряться, может банально забыть, что где-то там внутри может сгенериться исключение, особенно с чужой либой.

Один раз обработать это хорошо. А то по десять раз на одну ошибку IFов писать приходится. Надо глянуть в живую на подход. А ошибку все равно обрабатывать придется. Под исключением она просто может затеряться, может банально забыть, что где-то там внутри может сгенериться исключение, особенно с чужой либой.

Ты можешь так же легко принимать ошибки в _ как и проглатывать исключения. Тут разницы - никакой

Один раз обработать это хорошо. А то по десять раз на одну ошибку IFов писать приходится. Надо глянуть в живую на подход. А ошибку все равно обрабатывать придется. Под исключением она просто может затеряться, может банально забыть, что где-то там внутри может сгенериться исключение, особенно с чужой либой.

там, где исключения сделаны правильно - в яве - они не могут затеряться, они в контракт входят

а затеряться может RuntimeException, который аналог нашего panic

Еу тут хотя бы видно, что что-то проглотил, а с исключением не видно, а если оно там вообще в глубине сидит, то и забудется, пока не случится.

Го поговорочка номер последняя от пайка "don't Panic" ??? кстати, его доклад прикольный был

еще раз - все эксепшены, кроме Runtime, нельзя забыть, ты должен или поймать его, или объявить в контракте метода

еще раз - все эксепшены, кроме Runtime, нельзя забыть, ты должен или поймать его, или объявить в контракте метода

Это в джаве?

да

А в других не так.

в других эксепшены фуфло

в других эксепшены фуфло

в C++ вообще std::unexpected хэндлер есть, который необработанные исключения получает. Но мало кто о нем знает и это еще один способ отстрелить себе всё

Это не решение не обработанные получать, может там ошибка раз в год вылазить будет, только тогда и обнаружится, что где-то эксепшн какой-то не обработали.