Комментарии 10
Ммм, эта… а где про купленые дипломы?
а можно скрин как это выглядит?
P.S. интересно просто ;)
P.S. интересно просто ;)
В статье отмечено, что «Мы не будем говорить про отображение прогресс-индикатора» :-) С модулем прилагается простенький рендерер по умолчанию, который выводит в STDOUT примерно так:
Дорисуйте мысленно окошко вашего любимого терминала вокруг этой строчки :-)
Повторюсь, что модуль легко сдружить с любым GUI-компонентом или передавать прогресс на клиентскую сторону веб-приложения.
[##### ] 25.0% Processing
Дорисуйте мысленно окошко вашего любимого терминала вокруг этой строчки :-)
Повторюсь, что модуль легко сдружить с любым GUI-компонентом или передавать прогресс на клиентскую сторону веб-приложения.
Давайте скриншот в студию! Как это: такая статья, и без скриншота…
хмм, аналогичную задачу решал немного по-другому: весь процесс разбит на области, внутри которых привязка идет к относительным значениям (т.е. тупо ++ делается). В итоге самое сложное — согласовать области значений, но в итоге получается очень легко и элегантно.
Я уже почти сплю, поэтому до конца не буду сейчас расписывать, но предлагаю такую реализацию:
1) создаем процедуру, которая будет выполнять код с колбэком(первый параметр-код, второй-функция колбэка):
2) callback будет процедурой, которая будет получать параметрами текущее значение счетчика и его максимум, например:
3) самая сложная часть — анализатор кода, считающий что-то вроде общего «веса» кода(типа cost при explain'e SQL кода) и его частей, и вставляющий счетчики между частями. Ее я до конца не продумал, но предполагаю, что нужно сделать анализ всех циклов. Основная проблема будет со всякими вызовами функций которые вне данного кода.
1) создаем процедуру, которая будет выполнять код с колбэком(первый параметр-код, второй-функция колбэка):
sub progresseval{eval(addcounter(shift,shift));}
2) callback будет процедурой, которая будет получать параметрами текущее значение счетчика и его максимум, например:
sub callback{print shift*100/shift.'%';}
3) самая сложная часть — анализатор кода, считающий что-то вроде общего «веса» кода(типа cost при explain'e SQL кода) и его частей, и вставляющий счетчики между частями. Ее я до конца не продумал, но предполагаю, что нужно сделать анализ всех циклов. Основная проблема будет со всякими вызовами функций которые вне данного кода.
Совсем сплю — забыл сказать что третья часть и есть sub addcounter
Касательно веса отдельных подпроцессов у меня была мысль сделать самообучающийся прогресс-индикатор, так что результаты предыдущих прогонов (время, которое потребовалось на выполнение отдельных этапов) анализируются, и с их помощью корректируются проценты при следующих запусках этого же процесса. Заранее проанализировать не всегда возможно. Скажем, в длинном процессе первая часть напрягает процессор, а вторая — дисковую подсистему. Соотношение скоростей этих компонентов на машине пользователя заранее неизвестно.
> for_progress {sleep(1)} 1..10;
Если блок с кодом получается большой, то намного удобнее будет
То же самое для sub_progress.
В вашей библиотеке можно предусмотреть оба варианта использования функции, проверяя переданные параметры при помощи ref.
Если блок с кодом получается большой, то намного удобнее будет
for_progress 1..10, sub {
sleep(1);
sleep(2);
};
То же самое для sub_progress.
В вашей библиотеке можно предусмотреть оба варианта использования функции, проверяя переданные параметры при помощи ref.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Прогресс-индикатор со стеком