Разбивка выделения при закачке на части

[zed]

Окошки то откроются и все будет понятно. Рабочие потоки будут запускаться как сейчас, на вход им будет передаваться билдер, который по запросу будет начинать выполнение расчетов.

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

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

[vdemidov]

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

Смотри, подсчет тайлов в полигоне и так живет в отдельной функции. А вот выбор стартового тайла по относительному смещению это дело именно конкретного итератора. Так как оно будет совершенно разным для разных типов итераторов (спиральный, посточный, поколоночный и тд.). Так что именно в итераторе ему и место.

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

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

[zed]

Если я все правильно помню (нет кода перед глазами), сейчас итератор выполняет не свойственную ему работу - подсчет тайлов. Поскольку это число в самом итераторе никак не используется и в общем случае этот код надо бы вынести в какой-нибудь TileCountCalc. А ты теперь хочешь навесить на итератор еще одну задачу? Не надо. Лучше сделать RegionSplitter который сможет делить область как нам надо. А итератору мы только можем сказать чтобы он ходил не с начала и до конца, а с какой-то и до какой-то точки.

[zed]

Со спиральным итератором вообще все крайне сложно.

[zed]

В общем, достала меня эта тягомотина и после праздников буду делать так, как это себе представляю. Если по политическим причинам код не войдет в основную ветку, будет жить в форке. Вознаграждения от заказчика требовать не буду.

[vdemidov]

Если я все правильно помню (нет кода перед глазами), сейчас итератор выполняет не свойственную ему работу - подсчет тайлов. Поскольку это число в самом итераторе никак не используется и в общем случае этот код надо бы вынести в какой-нибудь TileCountCalc.

Он уже давно вызывает отдельную функцию.

Лучше сделать RegionSplitter который сможет делить область как нам надо.

Откуда этот RegionSplitter узнает порядок обхода? Это знает только конкретный итератор.

Со спиральным итератором вообще все крайне сложно.

Вот именно поэтому и нужно это делать только в конкретно одном итераторе по полигону.

[zed]

Он уже давно вызывает отдельную функцию.

А это не важно. Неужели тебе не понятно, что в этом месте, архитектурно, явно плохой код? И ты будешь спорить, что вынос считалки количества тайлов в отдельную сущность, ввиду высокой сложности задачи, является плохим решением? Особенно, в свете того, что есть/может быть несколько алгоритмов реализации подсчёта тайлов?

Откуда этот RegionSplitter узнает порядок обхода? Это знает только конкретный итератор.

А ему и не надо знать порядок. Ему надо разбить область так (на столько частей), чтобы любой итератор мог по ней пройтись. Т.е. если его попросить разбить область на 3 части, это не значит что он обязан вернуть 3 полигона. Он может вернуть 3 набора полигонов, по которым можно построить 3 итератора (если каждый набор полигонов представлен мультиполигоном) или 3 набора итераторов, если набор это одиночные полигоны/прямоугольники.

Потом, могут быть разные алгоритмы разбиения области. Вот тут заказчик просит разбить её по числу тайлов, а кому-то может захочется разбить на прямоугольники (как в примере в wiki) или ещё каким хитрым образом. А ты гвоздями прибиваешь это к итератору.

Вот именно поэтому и нужно это делать только в конкретно одном итераторе по полигону.

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

[Parasite]

Да, такой вариант возможен.

Можно ли как-то сделать так, чтобы патчить произвольно взятую текущую версию данной фичей? Батник+перепомпилирование там, или еще как-то...UX в процессе неважен - лишь бы фича работала потом на базе .current-версии.
?

будет жить в форке. Вознаграждения от заказчика требовать не буду.

Если хотелка будет работать согласно запрошенного - то она, разумеется, будет оплачена. В одной версии, или во всех - это уже детали (см. выше). Санта-Барбара со включением в основные ветки и прочий политес - не нужны.

[zed]

Можно ли как-то сделать так, чтобы патчить произвольно взятую текущую версию данной фичей?

Автоматически, конечно, не получится. Но руками, по запросу, вполне возможно будет смержиться с основной веткой.

[Parasite]

руками, по запросу

А батником, без запросов, и на моей стороне (с пошаговым описанием процесса мне, любимому)? Рекомпиляцию и прочее, разумеется - беру на себя, если будет описание процесса и все нужные тулзы (ну не программер я...).