Size: a a a

2019 November 17

AS

Andrew Shmatko in ErlangRus
почему не работает выражние [H|T| = Matrix.  Где Matrix - это двумерный массив ? Ожидаю что в H будет первый подмассив.
источник

MS

Mikhail Spiridonov in ErlangRus
1> [H|T] = [[1,1,1],[2,2,2]].
[[1,1,1],[2,2,2]]
2> H.
[1,1,1]
источник

ML

Maksim Lapshin in ErlangRus
Andrew Shmatko
почему не работает выражние [H|T| = Matrix.  Где Matrix - это двумерный массив ? Ожидаю что в H будет первый подмассив.
Потому что или у тебя не то в matrix, или h/t уже сматчились
источник

НД

Никодим Дьячёк in ErlangRus
Или потому что вместо скобки разделитель :)
источник

AS

Andrew Shmatko in ErlangRus
нашел лишние [ ]   )
источник

AS

Andrew Shmatko in ErlangRus
почему когда Matrix == [] выполняется первое уравнение , а не второе или третье?
http://i.imgur.com/Cl5NXM8.png
источник

СК

Сергей Крутский in ErlangRus
foo([],_,Acc) ->... нужно переместить до foo(Matrix,I,Acc)
источник

AG

Anton Grechnev in ErlangRus
потому что тебе надо функции местами поменять, матчинг срабатывает на первой функции
источник

AB

Alex Bubnov in ErlangRus
Andrew Shmatko
почему когда Matrix == [] выполняется первое уравнение , а не второе или третье?
http://i.imgur.com/Cl5NXM8.png
потому что клозы функции проверяются в порядке определения
источник

AB

Alex Bubnov in ErlangRus
соответственно, клозы завершения рекурсии должны быть описаны первыми, как уже сказали выше
источник

AS

Andrew Shmatko in ErlangRus
не знал об этом
странно, до этого как то писал и все работало)
спасибо
источник
2019 November 18

DR

Dmitry Russ (Aleksandrov) in ErlangRus
Привет! Вопрос по архитектуре и дизайну.

Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.

Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.

Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить debugger модуль, а основной процесс умеет только делать - attach_debugger, detach_debugger и добавляет в одном месте возможность обратиться к дебаггеру и блокируется и уже другой процесс отвечает за то, продолжить или остановиться и что делать с процессом.

Мне казалось правильнее, если процесс сам умеет обрабатывать вещи частями, а другой разработчик считает, что это должно быть не в buisness логике, а вообще отдельно и вот таким образом приделывает.

Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.
источник

СИ

Сергей Иванов in ErlangRus
Dmitry Russ (Aleksandrov)
Привет! Вопрос по архитектуре и дизайну.

Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.

Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.

Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить debugger модуль, а основной процесс умеет только делать - attach_debugger, detach_debugger и добавляет в одном месте возможность обратиться к дебаггеру и блокируется и уже другой процесс отвечает за то, продолжить или остановиться и что делать с процессом.

Мне казалось правильнее, если процесс сам умеет обрабатывать вещи частями, а другой разработчик считает, что это должно быть не в buisness логике, а вообще отдельно и вот таким образом приделывает.

Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.
За основной вопрос не скажу,но вот идея извлекать из системной и  хранить в своей мне не нравится. По системным очередям удобней как мониторить так и дампы смотреть
источник

DR

Dmitry Russ (Aleksandrov) in ErlangRus
Сергей Иванов
За основной вопрос не скажу,но вот идея извлекать из системной и  хранить в своей мне не нравится. По системным очередям удобней как мониторить так и дампы смотреть
Процесс GenServer - я хочу чтобы он отвечал на мои запросы, а он не может обработать определенные, что ему пришли, если находится в приостановленном состоянии.
источник

AB

Alex Bubnov in ErlangRus
Dmitry Russ (Aleksandrov)
Привет! Вопрос по архитектуре и дизайну.

Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.

Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.

Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить debugger модуль, а основной процесс умеет только делать - attach_debugger, detach_debugger и добавляет в одном месте возможность обратиться к дебаггеру и блокируется и уже другой процесс отвечает за то, продолжить или остановиться и что делать с процессом.

Мне казалось правильнее, если процесс сам умеет обрабатывать вещи частями, а другой разработчик считает, что это должно быть не в buisness логике, а вообще отдельно и вот таким образом приделывает.

Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.
мне нравится step-by-step дизайн, его можно вертеть в произвольном порядке
источник

DR

Dmitry Russ (Aleksandrov) in ErlangRus
В случае, если выносить в debugger, то нужно весь стейт копировать на каждый чих в debugger в случае включения дебаггера, ибо основной процесс завис на обработке последнего запроса, а чтобы его интроспектировать нужно иметь возможность получить любую информацию из стейта
источник

DR

Dmitry Russ (Aleksandrov) in ErlangRus
Alex Bubnov
мне нравится step-by-step дизайн, его можно вертеть в произвольном порядке
Мне тоже, чем больше я думаю об этом, тем больше мне он нравится.
источник

СИ

Сергей Иванов in ErlangRus
Dmitry Russ (Aleksandrov)
Привет! Вопрос по архитектуре и дизайну.

Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.

Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.

Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить debugger модуль, а основной процесс умеет только делать - attach_debugger, detach_debugger и добавляет в одном месте возможность обратиться к дебаггеру и блокируется и уже другой процесс отвечает за то, продолжить или остановиться и что делать с процессом.

Мне казалось правильнее, если процесс сам умеет обрабатывать вещи частями, а другой разработчик считает, что это должно быть не в buisness логике, а вообще отдельно и вот таким образом приделывает.

Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.
Новый разработчик пусть правит баги и добавляет фичи, а не переписывает работающий код ( давани авторитетом)
источник

DR

Dmitry Russ (Aleksandrov) in ErlangRus
Сергей Иванов
Новый разработчик пусть правит баги и добавляет фичи, а не переписывает работающий код ( давани авторитетом)
Это тех. директор включился в наш репозиторий, не такой он и новый, дольше меня в комманде.
источник

AB

Alex Bubnov in ErlangRus
Dmitry Russ (Aleksandrov)
В случае, если выносить в debugger, то нужно весь стейт копировать на каждый чих в debugger в случае включения дебаггера, ибо основной процесс завис на обработке последнего запроса, а чтобы его интроспектировать нужно иметь возможность получить любую информацию из стейта
никакой дебаггер не будет удобнее, чем крутануть степ-бай-степ редьюсом  в консоли, когда понадобится
источник