Как стать автором
Обновить

Комментарии 46

сорри забыл, уже второй раз :)
кат, кат. быстрее, быстрее!
спасибо, пригодится.
На заметку: следует учесть что реализация на основе setInterval не дает точной временной реализации. Т.е. если вам надо выполнить какоето действие в единицу времени (к примеру перемещение из точки А в точку Б за 1 секунду), то простым математическим путем вычисляем количество необходимых итераций N = 1сек/timeout, если timeout = 50мс, тогда N = 20. Т.е. необходимо 20 раз выполнить какойто код, а потом умереть. Изза специфики реализации setInterval и также изза нагрузки процессора (в это время сильно активно могут работать другие процессы) максимально вероятно что равномерность выполнения будет отсутствовать, особенно в разных браузерах будет по разному. Обычно (в extjs, jquery и др.) при необходимости выполнения какогого либо действия за единицу времени используют setTimeout с вычислением процента выполнения действия на основе разности времени предыдущей итерации с текущим временем. Т.е. процент выполнения вычисляется следующим образом:
var percent = (new Date().getTime() - start) / duration;
Ну и далее при percent >= 1 убивается цикл выполнения.
Спасибо. Думал на эту тему, не определся с выбором setInterval или setTimeout. Кстати первая версия была на базе setTimeout, скорее всего вернусь к ней с данными поправками.
setInterval также не очень будет, если проц вдруг загружен, и предыдущая итерация не закончилась. В ближайшем времени выложу перевод
http://ejohn.org/blog/how-javascript-tim…
НЛО прилетело и опубликовало эту надпись здесь
хабр, как обычно, порезал ссылку. Нужно русские буквы на английские заменить — все ок будет
>при percent >= 1 убивается цикл выполнения.

Разве нельзя сделать тоже в случае, если используется setInterval? Т.е., если исчерпан лимит времени, то вызвать clearInterval?
Если у Вас имеется, к примеру, всего одна секунда, то в случае, если сначала будет выполняться что-нибудь этакое:

var start = new Date;
while ((new Date) - start < 1000);

то и setInterval, и setTimeout окажутся в равном положении. Разве не так?
можно, но при использовании setInterval следующая итерация не зависит от предыдущей и соотвественно ею тяжелее управлять. Выбор принципа реализации зависит от конкретных задач. К примеру для реализации визуальных эффектов лучше использовать setTimeout.
>следующая итерация не зависит от предыдущей и соотвественно ею тяжелее управлять.

Что значит "не зависит", и что значит "тяжелее"?
Вообще, странно читать, что "что-то не зависит", ведь все в руках программиста, не так ли?

>зависит от конкретных задач.

Лично я именно с этого бы и начал. ;)

>для реализации визуальных эффектов лучше использовать setTimeout.

Как понимать это утверждение? Лучше для всех или просто удобней именно для Вас?
что бы понять, надо самому попробывать, или хотябы стремится к пониманию.
>что бы понять, надо самому попробывать...

Что именно "попробывать"? :)
Если серьезно, то по существу есть что добавить? Т.е. последуют ли комментарии, касающиеся сути вопроса (чтоб о Вас не создалось впечатление: "слышал звон, да не знает, где он" :) )?
Скажите, а под каким браузером работает Ваш сайт?.. Я попробовал Сафари, Фаерфокс и Оперу...
Сайт экспериментальный :) Хотя такие проблемы редки, в FF3.0rc1 есть проблема кстати с парсингом XML, причем в FF2.0+ все работало до FF3.0. Отлично было если бы Вы написали версии каждого браузера в которых проверяли. Заранее спасибо.

Столько кода и всё вокруг setInterval/setTimeout... Есть ли в этом смысл?
Всё это мне напоминает большое извращение. Зачем для реализации флагов городить битовые операции? Я ещё понимаю на С\С++ этим заниматься, но на js куда уместнее, имхо, простой хеш.


Как говорят многие "Prototype - для тех, кто не знает JavaScript" (хотя, помоему исходники прототипа можно читать как сказку - всё красиво и работает)


Самой полезной для меня информация был этот комментарий

Я с Вами полностью согласен . есть две функции, и я мало встречал, чтоб два или три процесса были одновремено запущены, так как будут непременно коллизии, лучше всегда делать 1 и в нем уже. а здесь очень уж наверчено, и не крос-броузерно.
Хотя это мое мнение .
Смотря что именно вы делаете, планировщик реально нужен бывает. Кстати, данное решение кросс-браузерное. Если вы про пример с сайтом, то проблемы там могут быть только с модулем для работы с SOAP(генерация xml).
я сгрировать стараюсь. чтоб не было коллизий, которые непремено бывают при связке аях + таймаут, так как после отправки вы начинаетет ждать ответа от него.
можно ввести идентификаторы запросов. если важен порядок прихода ответов, то аналогично различным потоковым протоколам ввести номер в цепочке. не очень уверен, что этим должен заниматься класс планировщика, скорее это отнести лучше к классу, который у вас данные передает и обрабатывает.
в любом случае немного будет тяжеловесно. я об этом и пишу, что целый класс для этого ИМХО много.
Так этот класс он не для этого, у него более широкие цели и задачи. Перед ним не ставится такой задачи, как отслеживания логики обработки SOAP-ответов.
Смысл есть, зависит от того, для чего вы это хотите использовать. Хотя здесь просто предлагалась идея. Про биты Vs хэш. Битовые флаги довольно наглядны для "классического" программиста и из них, имхо, удобнее создавать комбинации. И к чему цитата про прототайп?

ЗЫЖ на самом деле, можно просто смотреть и на этот, и на предыдущий код с процессами, как на красивую идею, если считаете, что js пока не дорос до таких задач, где это может применяться :)
Цитата к чему? не знаю, пол пятого утра было :)
Незадолго до этого прочитал статью, в которой выссказывалась мысль
если используете ЯВУ, то не стоит "опускаться" до байтов ( тем более битов :) )
гораздо эффективнее будет использование средства этого ЯВУ
Флаги можно комбинировать вот поэтому и выбор. Комментарий по поводу setTimeout полезный не спорю, думаю с sirus мы решим эту задачу :)
А хеши нет?
На вашем сайте еще бы не мешало историю реализовать :)
Какую историю?
кнопочки назад вперед браузера, не возможно перейти на предыдущую страницу не превычно кидает на первую
Хорошая идея, это можно сделать, в след. версии предусмотрим, так как это экспериментальная версия, где откатали технологии.
Движок для отображения карты - собственной разработки?

Извиняюсь за вопрос не в тему.
Имхо такое лучше писать в личку(или на почту), чтобы не оффтопить. Если интересно и я, и m007 ответим. А так там все свое, включая рендер карт.
Может проще вместо

Zero : function(dwFlag) { this.dwFlag &= (HFlag.MAX_FLAG_VALUE - dwFlag); }

сделать

Zero : function(dwFlag) { this.dwFlag &= ~dwFlag; }

И константа MAX_FLAG_VALUE не потребуется вовсе. К тому же если dwFlag будет больше MAX_FLAG_VALUE сдается мне будет не тот результат.
а можно прокомментировать? сколько работаю с ЖС ни разу не встречал оператор ~, что он делает? или это опечатка?
Это не опечатка. В 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).
НЛО прилетело и опубликовало эту надпись здесь
"На волне популярности любой веб проект может взлететь до небес и только программисты будут знать какой еб...ей заканчиваются попытки дальнейшего развития... " (с) Не мое.

В этом то и заключается простота один раз спрятав вроде бы "сложную" логику в класс (хотя если честно я ничего сверхестественного не предложил, просто конечный автомат и повесил на setInterval. Зато потом очень просто использовать фоновые задачи. Тоже самое предложено и в динимаческой загрузке скриптов, предыдущая статья.
Ммм... как бы так сказать...

Вы реализовали то, от чего стремились уйти разработчики JavaScript. А они далеко неспроста сделали JS однопоточным. Они тем самым избавили вас от сложностей параллельного программирования.

Кстати, мы с вами сейчас наблюдаем очередной виток технологической спирали :)
Идея витает в воздухе, возможно планировщик задач в некотором виде появится в популярных сегодня JS-фремворках и библиотеках, потом на основе них родится очередной подход к разработке клиентской части AJAX-приложений, возможно даже возникнет какая-то методология. Затем люде скорее всего перестанут справляться со сложностью всего этого хозяйства, за чем последую "урезанные" и "упрощенные" версии этих мегафреймворков. А потом очередной умелец реализует очередной планировщик задач "с блекджеком и шлюхами" на основе "упрощенного" мегафреймворка... и все начнется сначала :)

Мой коллега как-то сказал: "каждая программа стремится стать операционной системой". Подумайте, а надо ли оно, или все-таки стоит изыскать средства, более подходящие для решения ваших задач?
Мдя, в своё время писал на JS мютекс/симафор/планировщик задач... Препод не поддержал моей инициативы, и не принял такие варианты.
НЛО прилетело и опубликовало эту надпись здесь
Вот опирационка в инете http://eyeos.info/
НЛО прилетело и опубликовало эту надпись здесь
возникла мысль, при плотном использовании такого "планировщика" можно реализовать более менее вменяемый sleep
брр, какая жуткая нотация кода :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории