⌬C
хм, вот вопрос такой - а зачем народ заморачивается с очередью каллбеков если можно просто вызвать сохраненные в свойствах функции?
то есть?
Size: a a a
2020 October 08
⌬C
Обычно такие проблемы становятся явными при написании тестов
а как их написать правильно?
DP
так а в чем проблема?
АП
type MyLib struct {
MyCallback func()
}
func (l *MyLib) Run() {
go func() {
for {
l.MyCallback()
}
}()
}АП
так вот вместо прямого вызова
MyCallback, заморачиваются с мьютексами, какие то очередь каллбековDP
я бы в директорию testdata сложил бы файликов с бинарными данными, и рядом с результатами
из файликов бы читал, и сравнивал, что получится
из файликов бы читал, и сравнивал, что получится
⌬C
так а в чем проблема?
в большом количестве кейсов и их нечитаемости. никогда с подобным не сталкивался, просто может вместо []byte{0xab, 0xcd, ...} можно что-то более читаемым сделать
⌬C
всмысле не можно, а было бы желательно, но непонятно как)
MA
Помогите пожалуйста со слайсами:
arr := []uint{1,2,3,4,5}
fmt.Println(arr[0:2])
При выводе печатает [1,2], я понимаю, что счет идёт с нуля, но почему конечный элемент 2, является 0:2(!) а не 0:1, ведь отчет идёт с нуля, поэтому по логике я думал, что 0:1 это будет [1,2]AK
0 + 1 = 1
SP
всмысле не можно, а было бы желательно, но непонятно как)
(меня сюда позвали из дргугого чата). Я когда писал mtproto proxy, то для кодеков написал property-based тесты. Но у меня есть как свой endoder так и decoder. Так что я просто кодировал и раскодировал своими же кодеками рандомно сгенерированный payload. В том числе поточно а не по целым пакетам.
Прикольная тема с property based тестами это то, что фреймворк (если лн это поддерживает) постарается в случае падения теста ватоматически подобрать минимальный пример который воспроизводит падение
Прикольная тема с property based тестами это то, что фреймворк (если лн это поддерживает) постарается в случае падения теста ватоматически подобрать минимальный пример который воспроизводит падение
AK
Mr Ash
Помогите пожалуйста со слайсами:
arr := []uint{1,2,3,4,5}
fmt.Println(arr[0:2])
При выводе печатает [1,2], я понимаю, что счет идёт с нуля, но почему конечный элемент 2, является 0:2(!) а не 0:1, ведь отчет идёт с нуля, поэтому по логике я думал, что 0:1 это будет [1,2]ну очевидно 0:2 это Вы делаете срез с 0 элемента на 2 элемента, вот и результат 1,2
AK
а 0:1 это срез с 0 элемента на 1 элемент
MA
ну очевидно 0:2 это Вы делаете срез с 0 элемента на 2 элемента, вот и результат 1,2
блин спасибо большое, максимально понятно стало, еще почитаю и точно буду разбираться, уже второй день практикуюсь
AK
Всем добрый вечер. Столкнулся с довольно странной проблемой. У меня примерно такая система обработки команд в чат-боте: https://play.golang.org/p/lv_DQBgfm_z
Проблема в том, что для любой команды бот выполняет действие, соответствующее последней переданной в RegisterCommands. Т.е. где-то в этом методе я накосячил, но я не могу понять где. Я, должно быть, что-то не так понимаю либо про тонкости inline-функций, либо про for range, либо ещё про что-то.
У меня есть гипотеза, что функции в мапе хранятся по указателям и при итерации по срезу используется один и тот же адрес для элемента, т.е. в мапу кладётся один и тот же поинтер, чьё значение изменяется по ходу итерации и в конце становится равным указателю на action последней команды. Если это так, то как наименее криво это пофиксить?
Проблема в том, что для любой команды бот выполняет действие, соответствующее последней переданной в RegisterCommands. Т.е. где-то в этом методе я накосячил, но я не могу понять где. Я, должно быть, что-то не так понимаю либо про тонкости inline-функций, либо про for range, либо ещё про что-то.
У меня есть гипотеза, что функции в мапе хранятся по указателям и при итерации по срезу используется один и тот же адрес для элемента, т.е. в мапу кладётся один и тот же поинтер, чьё значение изменяется по ходу итерации и в конце становится равным указателю на action последней команды. Если это так, то как наименее криво это пофиксить?
AK
Всем добрый вечер. Столкнулся с довольно странной проблемой. У меня примерно такая система обработки команд в чат-боте: https://play.golang.org/p/lv_DQBgfm_z
Проблема в том, что для любой команды бот выполняет действие, соответствующее последней переданной в RegisterCommands. Т.е. где-то в этом методе я накосячил, но я не могу понять где. Я, должно быть, что-то не так понимаю либо про тонкости inline-функций, либо про for range, либо ещё про что-то.
У меня есть гипотеза, что функции в мапе хранятся по указателям и при итерации по срезу используется один и тот же адрес для элемента, т.е. в мапу кладётся один и тот же поинтер, чьё значение изменяется по ходу итерации и в конце становится равным указателю на action последней команды. Если это так, то как наименее криво это пофиксить?
Проблема в том, что для любой команды бот выполняет действие, соответствующее последней переданной в RegisterCommands. Т.е. где-то в этом методе я накосячил, но я не могу понять где. Я, должно быть, что-то не так понимаю либо про тонкости inline-функций, либо про for range, либо ещё про что-то.
У меня есть гипотеза, что функции в мапе хранятся по указателям и при итерации по срезу используется один и тот же адрес для элемента, т.е. в мапу кладётся один и тот же поинтер, чьё значение изменяется по ходу итерации и в конце становится равным указателю на action последней команды. Если это так, то как наименее криво это пофиксить?
goland можно debug включить и по строчке смотреть что происходит у Вас. Там и какие данные приходят и какие уходят
⌬C
(меня сюда позвали из дргугого чата). Я когда писал mtproto proxy, то для кодеков написал property-based тесты. Но у меня есть как свой endoder так и decoder. Так что я просто кодировал и раскодировал своими же кодеками рандомно сгенерированный payload. В том числе поточно а не по целым пакетам.
Прикольная тема с property based тестами это то, что фреймворк (если лн это поддерживает) постарается в случае падения теста ватоматически подобрать минимальный пример который воспроизводит падение
Прикольная тема с property based тестами это то, что фреймворк (если лн это поддерживает) постарается в случае падения теста ватоматически подобрать минимальный пример который воспроизводит падение
то есть в итоге:
правильно бы написать кучу перекучу тестов в разных вариациях, раскидать их по файликам в папку типа references (а как стати можно назвать директорию с тест кейсами вот еще интересный вопрос), и написать большой тест, который будет сам определять где ошибка? ну типа, если я правильно понима, то так.
но окей, даже если так — как правильно в стриме байт отлавливать некорректную последовательность или сообщение? даже хрен с ним, не в конкретно го, а вообще, алгоритмически
и кстати, разве рандом в тестах хорошо?
правильно бы написать кучу перекучу тестов в разных вариациях, раскидать их по файликам в папку типа references (а как стати можно назвать директорию с тест кейсами вот еще интересный вопрос), и написать большой тест, который будет сам определять где ошибка? ну типа, если я правильно понима, то так.
но окей, даже если так — как правильно в стриме байт отлавливать некорректную последовательность или сообщение? даже хрен с ним, не в конкретно го, а вообще, алгоритмически
и кстати, разве рандом в тестах хорошо?
AK
то есть в итоге:
правильно бы написать кучу перекучу тестов в разных вариациях, раскидать их по файликам в папку типа references (а как стати можно назвать директорию с тест кейсами вот еще интересный вопрос), и написать большой тест, который будет сам определять где ошибка? ну типа, если я правильно понима, то так.
но окей, даже если так — как правильно в стриме байт отлавливать некорректную последовательность или сообщение? даже хрен с ним, не в конкретно го, а вообще, алгоритмически
и кстати, разве рандом в тестах хорошо?
правильно бы написать кучу перекучу тестов в разных вариациях, раскидать их по файликам в папку типа references (а как стати можно назвать директорию с тест кейсами вот еще интересный вопрос), и написать большой тест, который будет сам определять где ошибка? ну типа, если я правильно понима, то так.
но окей, даже если так — как правильно в стриме байт отлавливать некорректную последовательность или сообщение? даже хрен с ним, не в конкретно го, а вообще, алгоритмически
и кстати, разве рандом в тестах хорошо?
я бы директорию назвал бы tests
SP
то есть в итоге:
правильно бы написать кучу перекучу тестов в разных вариациях, раскидать их по файликам в папку типа references (а как стати можно назвать директорию с тест кейсами вот еще интересный вопрос), и написать большой тест, который будет сам определять где ошибка? ну типа, если я правильно понима, то так.
но окей, даже если так — как правильно в стриме байт отлавливать некорректную последовательность или сообщение? даже хрен с ним, не в конкретно го, а вообще, алгоритмически
и кстати, разве рандом в тестах хорошо?
правильно бы написать кучу перекучу тестов в разных вариациях, раскидать их по файликам в папку типа references (а как стати можно назвать директорию с тест кейсами вот еще интересный вопрос), и написать большой тест, который будет сам определять где ошибка? ну типа, если я правильно понима, то так.
но окей, даже если так — как правильно в стриме байт отлавливать некорректную последовательность или сообщение? даже хрен с ним, не в конкретно го, а вообще, алгоритмически
и кстати, разве рандом в тестах хорошо?
> написать кучу перекучу тестов в разных вариациях, раскидать их по файликам
в моём случае на вход теста подаётся случайно сгенерированный бинарь (он генерируется property-based test фреймворком). Тест его кодирует енкодером, потом то что получилось декодирует декодером (возможно по частям), потом сравнивает что изначально в тест зашло и что вышло. если в процессе кодирования/декодирования что-то крешнулось или бинари не совпали, то считаем что тест сфейлился. после этого property-based фреймворк начинает процедуру shrinking: уменьшает размер бинаря и упрощает его (заменяет байты на 0) до тех пор пока падение теста воспроизводится
в моём случае на вход теста подаётся случайно сгенерированный бинарь (он генерируется property-based test фреймворком). Тест его кодирует енкодером, потом то что получилось декодирует декодером (возможно по частям), потом сравнивает что изначально в тест зашло и что вышло. если в процессе кодирования/декодирования что-то крешнулось или бинари не совпали, то считаем что тест сфейлился. после этого property-based фреймворк начинает процедуру shrinking: уменьшает размер бинаря и упрощает его (заменяет байты на 0) до тех пор пока падение теста воспроизводится