Прогресс-индикатор со стеком

[Frosty]

Ммм, эта… а где про купленые дипломы?

[or10n]

а можно скрин как это выглядит?
P.S. интересно просто ;)

[tagir_valeev]

В статье отмечено, что «Мы не будем говорить про отображение прогресс-индикатора» :-) С модулем прилагается простенький рендерер по умолчанию, который выводит в STDOUT примерно так:

[#####               ] 25.0% Processing

Дорисуйте мысленно окошко вашего любимого терминала вокруг этой строчки :-)

Повторюсь, что модуль легко сдружить с любым GUI-компонентом или передавать прогресс на клиентскую сторону веб-приложения.

[oe24]

Давайте скриншот в студию! Как это: такая статья, и без скриншота…

[sunnybear]

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

[xtender]

Я уже почти сплю, поэтому до конца не буду сейчас расписывать, но предлагаю такую реализацию:
1) создаем процедуру, которая будет выполнять код с колбэком(первый параметр-код, второй-функция колбэка):

sub progresseval{eval(addcounter(shift,shift));}

2) callback будет процедурой, которая будет получать параметрами текущее значение счетчика и его максимум, например:

sub callback{print shift*100/shift.'%';}

3) самая сложная часть — анализатор кода, считающий что-то вроде общего «веса» кода(типа cost при explain'e SQL кода) и его частей, и вставляющий счетчики между частями. Ее я до конца не продумал, но предполагаю, что нужно сделать анализ всех циклов. Основная проблема будет со всякими вызовами функций которые вне данного кода.

[xtender]

Совсем сплю — забыл сказать что третья часть и есть sub addcounter

[tagir_valeev]

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

[Biga]

> for_progress {sleep(1)} 1..10;

Если блок с кодом получается большой, то намного удобнее будет

for_progress 1..10, sub {
    sleep(1);
    sleep(2);
};

То же самое для sub_progress.
В вашей библиотеке можно предусмотреть оба варианта использования функции, проверяя переданные параметры при помощи ref.

[tagir_valeev]

Да, насчёт for_progress разумно, сделаю.
С sub_progress, мне кажется, смысла немного, потому что процент логичнее помещать в конце даже большого блока:
sub_progress {
...
} 50; # процент на момент завершения блокаЕсли размещать его перед блоком, кажется немного непоследовательно. Но я ещё подумаю.