Комментарии 46
хабракат
-4
кат, кат. быстрее, быстрее!
-3
спасибо, пригодится.
0
На заметку: следует учесть что реализация на основе setInterval не дает точной временной реализации. Т.е. если вам надо выполнить какоето действие в единицу времени (к примеру перемещение из точки А в точку Б за 1 секунду), то простым математическим путем вычисляем количество необходимых итераций N = 1сек/timeout, если timeout = 50мс, тогда N = 20. Т.е. необходимо 20 раз выполнить какойто код, а потом умереть. Изза специфики реализации setInterval и также изза нагрузки процессора (в это время сильно активно могут работать другие процессы) максимально вероятно что равномерность выполнения будет отсутствовать, особенно в разных браузерах будет по разному. Обычно (в extjs, jquery и др.) при необходимости выполнения какогого либо действия за единицу времени используют setTimeout с вычислением процента выполнения действия на основе разности времени предыдущей итерации с текущим временем. Т.е. процент выполнения вычисляется следующим образом:
var percent = (new Date().getTime() - start) / duration;
Ну и далее при percent >= 1 убивается цикл выполнения.
var percent = (new Date().getTime() - start) / duration;
Ну и далее при percent >= 1 убивается цикл выполнения.
+5
Спасибо. Думал на эту тему, не определся с выбором setInterval или setTimeout. Кстати первая версия была на базе setTimeout, скорее всего вернусь к ней с данными поправками.
0
setInterval также не очень будет, если проц вдруг загружен, и предыдущая итерация не закончилась. В ближайшем времени выложу перевод
http://ejohn.org/blog/how-javascript-tim…
http://ejohn.org/blog/how-javascript-tim…
0
>при percent >= 1 убивается цикл выполнения.
Разве нельзя сделать тоже в случае, если используется setInterval? Т.е., если исчерпан лимит времени, то вызвать clearInterval?
Если у Вас имеется, к примеру, всего одна секунда, то в случае, если сначала будет выполняться что-нибудь этакое:
то и setInterval, и setTimeout окажутся в равном положении. Разве не так?
Разве нельзя сделать тоже в случае, если используется setInterval? Т.е., если исчерпан лимит времени, то вызвать clearInterval?
Если у Вас имеется, к примеру, всего одна секунда, то в случае, если сначала будет выполняться что-нибудь этакое:
var start = new Date;
while ((new Date) - start < 1000);
то и setInterval, и setTimeout окажутся в равном положении. Разве не так?
0
можно, но при использовании setInterval следующая итерация не зависит от предыдущей и соотвественно ею тяжелее управлять. Выбор принципа реализации зависит от конкретных задач. К примеру для реализации визуальных эффектов лучше использовать setTimeout.
0
>следующая итерация не зависит от предыдущей и соотвественно ею тяжелее управлять.
Что значит "не зависит", и что значит "тяжелее"?
Вообще, странно читать, что "что-то не зависит", ведь все в руках программиста, не так ли?
>зависит от конкретных задач.
Лично я именно с этого бы и начал. ;)
>для реализации визуальных эффектов лучше использовать setTimeout.
Как понимать это утверждение? Лучше для всех или просто удобней именно для Вас?
Что значит "не зависит", и что значит "тяжелее"?
Вообще, странно читать, что "что-то не зависит", ведь все в руках программиста, не так ли?
>зависит от конкретных задач.
Лично я именно с этого бы и начал. ;)
>для реализации визуальных эффектов лучше использовать setTimeout.
Как понимать это утверждение? Лучше для всех или просто удобней именно для Вас?
0
что бы понять, надо самому попробывать, или хотябы стремится к пониманию.
0
Скажите, а под каким браузером работает Ваш сайт?.. Я попробовал Сафари, Фаерфокс и Оперу...
0
sCheduler
0
Столько кода и всё вокруг setInterval/setTimeout... Есть ли в этом смысл?
Всё это мне напоминает большое извращение. Зачем для реализации флагов городить битовые операции? Я ещё понимаю на С\С++ этим заниматься, но на js куда уместнее, имхо, простой хеш.
Как говорят многие "Prototype - для тех, кто не знает JavaScript" (хотя, помоему исходники прототипа можно читать как сказку - всё красиво и работает)
Самой полезной для меня информация был этот комментарий
-1
Я с Вами полностью согласен . есть две функции, и я мало встречал, чтоб два или три процесса были одновремено запущены, так как будут непременно коллизии, лучше всегда делать 1 и в нем уже. а здесь очень уж наверчено, и не крос-броузерно.
Хотя это мое мнение .
Хотя это мое мнение .
0
Смотря что именно вы делаете, планировщик реально нужен бывает. Кстати, данное решение кросс-браузерное. Если вы про пример с сайтом, то проблемы там могут быть только с модулем для работы с SOAP(генерация xml).
0
я сгрировать стараюсь. чтоб не было коллизий, которые непремено бывают при связке аях + таймаут, так как после отправки вы начинаетет ждать ответа от него.
0
Смысл есть, зависит от того, для чего вы это хотите использовать. Хотя здесь просто предлагалась идея. Про биты Vs хэш. Битовые флаги довольно наглядны для "классического" программиста и из них, имхо, удобнее создавать комбинации. И к чему цитата про прототайп?
ЗЫЖ на самом деле, можно просто смотреть и на этот, и на предыдущий код с процессами, как на красивую идею, если считаете, что js пока не дорос до таких задач, где это может применяться :)
ЗЫЖ на самом деле, можно просто смотреть и на этот, и на предыдущий код с процессами, как на красивую идею, если считаете, что js пока не дорос до таких задач, где это может применяться :)
0
Флаги можно комбинировать вот поэтому и выбор. Комментарий по поводу setTimeout полезный не спорю, думаю с sirus мы решим эту задачу :)
0
На вашем сайте еще бы не мешало историю реализовать :)
0
Движок для отображения карты - собственной разработки?
Извиняюсь за вопрос не в тему.
Извиняюсь за вопрос не в тему.
0
Может проще вместо
сделать
И константа MAX_FLAG_VALUE не потребуется вовсе. К тому же если dwFlag будет больше MAX_FLAG_VALUE сдается мне будет не тот результат.
Zero : function(dwFlag) { this.dwFlag &= (HFlag.MAX_FLAG_VALUE - dwFlag); }
сделать
Zero : function(dwFlag) { this.dwFlag &= ~dwFlag; }
И константа MAX_FLAG_VALUE не потребуется вовсе. К тому же если dwFlag будет больше MAX_FLAG_VALUE сдается мне будет не тот результат.
0
а можно прокомментировать? сколько работаю с ЖС ни разу не встречал оператор ~, что он делает? или это опечатка?
0
Это не опечатка. В ECMAScript Language действительно есть такой оператор и делает он тоже самое, что и, к примеру, в С++:
MSDN:
…every bit that is 1 in the operand is 0 in the result. Conversely, every bit that is 0 in the operand is 1 in the result.
т.е. это оператор двоичной инверсии (Bitwise NOT).
MSDN:
…every bit that is 1 in the operand is 0 in the result. Conversely, every bit that is 0 in the operand is 1 in the result.
т.е. это оператор двоичной инверсии (Bitwise NOT).
0
НЛО прилетело и опубликовало эту надпись здесь
"На волне популярности любой веб проект может взлететь до небес и только программисты будут знать какой еб...ей заканчиваются попытки дальнейшего развития... " (с) Не мое.
В этом то и заключается простота один раз спрятав вроде бы "сложную" логику в класс (хотя если честно я ничего сверхестественного не предложил, просто конечный автомат и повесил на setInterval. Зато потом очень просто использовать фоновые задачи. Тоже самое предложено и в динимаческой загрузке скриптов, предыдущая статья.
В этом то и заключается простота один раз спрятав вроде бы "сложную" логику в класс (хотя если честно я ничего сверхестественного не предложил, просто конечный автомат и повесил на setInterval. Зато потом очень просто использовать фоновые задачи. Тоже самое предложено и в динимаческой загрузке скриптов, предыдущая статья.
0
Ммм... как бы так сказать...
Вы реализовали то, от чего стремились уйти разработчики JavaScript. А они далеко неспроста сделали JS однопоточным. Они тем самым избавили вас от сложностей параллельного программирования.
Кстати, мы с вами сейчас наблюдаем очередной виток технологической спирали :)
Идея витает в воздухе, возможно планировщик задач в некотором виде появится в популярных сегодня JS-фремворках и библиотеках, потом на основе них родится очередной подход к разработке клиентской части AJAX-приложений, возможно даже возникнет какая-то методология. Затем люде скорее всего перестанут справляться со сложностью всего этого хозяйства, за чем последую "урезанные" и "упрощенные" версии этих мегафреймворков. А потом очередной умелец реализует очередной планировщик задач "с блекджеком и шлюхами" на основе "упрощенного" мегафреймворка... и все начнется сначала :)
Мой коллега как-то сказал: "каждая программа стремится стать операционной системой". Подумайте, а надо ли оно, или все-таки стоит изыскать средства, более подходящие для решения ваших задач?
Вы реализовали то, от чего стремились уйти разработчики JavaScript. А они далеко неспроста сделали JS однопоточным. Они тем самым избавили вас от сложностей параллельного программирования.
Кстати, мы с вами сейчас наблюдаем очередной виток технологической спирали :)
Идея витает в воздухе, возможно планировщик задач в некотором виде появится в популярных сегодня JS-фремворках и библиотеках, потом на основе них родится очередной подход к разработке клиентской части AJAX-приложений, возможно даже возникнет какая-то методология. Затем люде скорее всего перестанут справляться со сложностью всего этого хозяйства, за чем последую "урезанные" и "упрощенные" версии этих мегафреймворков. А потом очередной умелец реализует очередной планировщик задач "с блекджеком и шлюхами" на основе "упрощенного" мегафреймворка... и все начнется сначала :)
Мой коллега как-то сказал: "каждая программа стремится стать операционной системой". Подумайте, а надо ли оно, или все-таки стоит изыскать средства, более подходящие для решения ваших задач?
0
Мдя, в своё время писал на JS мютекс/симафор/планировщик задач... Препод не поддержал моей инициативы, и не принял такие варианты.
0
НЛО прилетело и опубликовало эту надпись здесь
возникла мысль, при плотном использовании такого "планировщика" можно реализовать более менее вменяемый sleep
0
брр, какая жуткая нотация кода :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Планировщик задач на JavaScript