Владимир написал: Если не понимаете, то не читайте. Классификатор Вы наш.
Это трудно назвать ответом на заданные вопросы. И, похоже, вы не понимаете деструктивность своего поведения. Хотя, наверное, вам понять трудно, попытаюсь объяснить деструктивность вашего поведения. 1. Вы издеваетесь над читателями, так как прежде чем что-то прочесть, им приходится пролистывать ваш спам. 2. Вы, похоже, не способны упустить халявную возможность писать длинные комментарии и скоро переполните базу форума . 3. Работая прокладкой между комментариями, вы ухудшаете свой имидж.
Зачем вы постоянно гадите на форуме чужими длинными текстами? Вы испытываете терпение поддержки QUIK? Вы думаете, что чем длиннее ваши комментарии, тем умнее выглядите? Помните, что говорил А.П. Чехов?:"Краткость, сестра таланта" . И куда вы относитесь по этой классификации?
VPM написал: Переписал у себя т. всех сделок как показывает TGB ,
В выложенном мною коде есть ошибка в строке:
Цитата
TGB написал: for i = NumberOf - 1, NumberOf_t - 1 do -- индексы в таблицах QUIK начинаются с 0 --
Должно быть: for i = NumberOf , NumberOf_t - 1 do -- индексы в таблицах QUIK начинаются с 0 -- --------------------------
Цитата
Владимир написал: раз в сто быстрее, чем обращение к таблице Квика. Но это мелочь
Согласен (хотя сто это "сильное" утверждение).
Цитата
Владимир написал: Те самые прерывания, которые поступают в Квик не только передаются скрипту в OnTrade, но и вызывают перезапись таблицы сделок - я сам видел нули в некоторых полях этой таблицы (в айдишках заявок, транзакций, в цене - кажется, когда-то об этом писал), так что данные в строках таблицы не всегда сразу "устаканиваются".
С этим я не сталкивался (все нужные мне поля для анализа сделки получаю), но если это так, то просьба к поддержке: подтвердить это. ----
Цитата
Владимир написал: Он всегда вырабатывает ВСЕ появившиеся записи, даже если их придёт несколько десятков или сотен.
Я не очень понимаю почему сделки нельзя обрабатывать "пачкой", но код легко изменить так, чтобы при его вызове обрабатывалось не более одной сделки.
Цитата
Владимир написал: проблемы, и очень серьёзные: нужно ведь опознать, по какой ЗАЯВКЕ пришла эта сделка. У меня-то на этот случай есть стек активных заявок, а Вы что будете делать?
Нет проблем. В считанной из таблицы сделок есть поле order_num. Это поле номер заявки, по которой выполнилась сделка. И вы легко можете опознать, по какой ЗАЯВКЕ пришла эта сделка.
Цитата
Владимир написал: А если это вообще "левая" заявка, поданная вручную, в обход скрипта через стакан?
Если в вашем стеке активных заявок, нет заявки, соответствующей считанной сделки, то можете, считать, что заявка подана вручную.
Владимир написал: Сделки немедленно попадают в стек прерываний и выбираются оттуда 4 раза в секунду, обычно по одной, но если там дубль уже обработанной (тоже тот ещё маразм: несколько прерываний на одно событие!), то по 2 или 3 элемента за раз.
Можно выбирать 4 раза в секунду новые сделки из таблицы сделок и при этом не требуется ведения стека прерываний, борьбы с дублями колбеков, которые к тому же выполняются в потоке, отличном от main, а потому, по-хорошему, надо учитывать и то, что у вас со стеком ведется работа из двух потоков. Фрагмент эффективной обработки таблицы сделок:
Код
--- Инициализация -----
local NumberOf = 0 ---- сохраненная длина таблицы сделок --
local NumberOf_t --
local tbl_trades
-------
-- Фрагмент чтения новых сделок (4 раза в секунду ) ---
NumberOf_t = getNumberOf ('trades') --- быстрая операция ---
if NumberOf_t > NumberOf then -- обработка всех новых возникших сделок --
for i = NumberOf - 1, NumberOf_t - 1 do -- индексы в таблицах QUIK начинаются с 0 --
tbl_trades = getItem ('trades', i) -- быстрая операция (прямое чтение по индексу) ---
--- дальнейшая обработка новых сделок ---
----------------------------------------
end
NumberOf = NumberOf_t -- сохранение длины таблицы сделок --
end
Владимир написал: Затем, что сделки приходят в случайные моменты времени, алгоритмически они и есть прерывания.
Если я правильно понимаю, вам в скрипте надо знать состояние вашего счета по сделкам. Зачем вам обрабатывать колбеки сделок в случайные моменты времени (дополнительный "геморрой"), когда вы можете посмотреть (только) изменения в таблице сделок (конечный результат), и это можно сделать просто и эффективно. Если между просмотрами таблицы сделок, возникнет несколько новых, то вы их все равно увидите. Задержка 2-3 секунды (из-за цикла просмотра таблицы) в получении состояния по сделкам вряд ли, для вас существенна, так как QUIK точно не HFT терминал.
Владимир написал: Единственный коллбек, который использую я - OnTrade, некоторые работают даже без него.
Вы до сих пор используете OnTrade? Зачем реагировать на полуфабрикаты (колбеки), когда можно использовать текущее состояние QUiK (таблица по сделкам)? Вы же не занимаетесь FTP (зачем? и точно бессмысленное занятие этим в quik)? Чем проще, тем надежнее.
nikolz написал: Один компьютер может обсчитывать очень сложный алгоритм по одному инструменту в реальном времени. Например нейронную сеть на 1 миллиард нейронных связей. ------------------------Делаем в интернет пул скажем 1000 компьютеров Получаем распределенный кластер прогнозирования 1000 инструментов в реальном времени.
. «Остапа понесло ….. Остап со вчерашнего дня еще ничего не ел. Поэтому красноречие его было необыкновенно» Ильф и Петров: «Двенадцать стульев»
nikolz написал: Форум не церковь, а я вам не поп, чтобы слушать Вашу исповедь.
Короткий ответ с элементами юмора радует. Это путь к исправлению. Но вы опять что-то перепутали, скорее я выступил в роли попа со своими наставлениями .
nikolz Ожидаемо, что вам не захотелось продолжения нашего «банкета», но чтобы у вас, и мысли продолжения его не возникли далее (вы мне надоели), то я сам его и завершу. Мне, совершенно, не интересно с вами общаться. Что-то вам объяснить, это неразрешимая задача (на уровне, попытки объяснения обезьяне тензорного исчисления). Но, я в мягкой форме и неоднократно пытался вам объяснить, предельно простую мысль, что вам не надо много писать на форуме, пока вы не сможете читать . А если это и произойдет (вы сможете читать) то, похоже, очень не скоро . Вам вредно изображать из себя «гуру программирования». Вам это не идет. Вы что, не понимаете, что вы смешны со своими сотнями потоками? Вы несчастный человек. Вам не надо заниматься сложными вещами. Вам, наверное, надо как то осознать ваше реальное место в этой жизни. Вы не торгуете на фондовом рынке, хоть и заявляете о каких то «бешенных» процентах. У вас нет приличной работы. Ну кто, в здравом уме, примет вас на приличную работу? Вы безработный или полубезработный и работаете на данном форуме «прокладкой» между комментариями пользователей.
Пропустил тяжкое обвинение (дополнительное подтверждение написанного ранее о вас):
Цитата
nikolz написал: Судя по Вашим постам Вы не умеете использовать механизмы синхронизации потоков.
Если бы вы умели читать мои комментарии и при этом еще что-то соображать (а это, к сожалению, точно не лечится ), то вы могли бы, наверное, понять, что это ваше очередное заблуждение. ------------ Кстати (о заблуждениях):
Цитата
nikolz написал: Локальные стеки у луа машин майн и основного потока разные и следовательно синхронизация потоков при обращении к ним не требуется и нет блокировки.
Вы что, до сих пор не сообразили, что когда мы с вами «муторно» обсуждали коды на C++, то lua_lock(L) и lua_unlock(L) это те самые блокировки, которые, по вашему мнению, отсутствуют. ------------------------------ Если же вам захочется продолжение нашего «банкета» , то оно будет.
nikolz написал: Разработчики КВИКА к разработке VMLua имеют ровно такое же отношение как мы с вами - т е НИКАКОГО.
Я нигде не писал, что разработчики КВИКА разрабатывали VMLua. Но за все ошибки, которые возникают в КВИКе, независимо от того, что разработчик использовал при его создании, отвечают он. Вы какой-то сильно непонятливый. Но попробую объяснить вам это на простом примере. Возможно, вы ездите на своей машине. В ней наверняка используется электроника, которую производитель закупал на стороне. Например, эта электроника сломалась. Вы что, побежите со своими претензиями к производителю электроники?
nikolz написал: else {size_t l; const char *s = lua_tolstring (L, 1, &l); if (s != NULL && lua_stringtonumber (L, s) == l + 1)return 1; /* successful conversion to number *//* else not a number */ } } в этой части преобразуется строка в число и используется функция lua_tolstring ранее уже показывал, повторю:
А функция lua_stringtonumber для вас, конечно, не существует. Вы думаете, что она никогда не вызывается? Даже если надо преобразовать число, представленное в виде строки? Вы все-таки читайте то, что я пишу. Я же дал вам ссылку на свой разбор ситуации. И эта ссылка многократно повторялась ранее. Но для вас повторю написанное мной ранее (цитирую себя): ---- При просмотре исходника функции tonumber (с учетом вызываемых в ней функций), я обнаружил, что в этой функции есть как минимум один фрагмент с использованием операций в L без синхронизирующих скобок (мои комментарии помечены в исходнике символами #####). !!! lua_stringtonumber вызывается в tonumber: LUA_API size_t lua_stringtonumber (lua_State *L, const char *s) { size_t sz = luaO_str2num(s, s2v(L->top)); // ##### ? используется L без синхронизирующих скобок if (sz != 0) api_incr_top(L); // ##### ? используется L без синхронизирующих скобок return sz; } Возможно, что-то я упустил, но пусть это проверит разработчик QUIK. ---- В конструкциях luaO_str2num и api_incr_top в качестве параметров используется L. Найдите в этих конструкциях синхронизирующие скобки lua_unlock(L); lua_lock(L) и тогда мы продолжим общение.
Не ту функцию с вами обсуждаем (смотрите мой предыдущий комментарий) . Напрасно я вам мозги "пудрил". Но вы меня не читаете. Давно бы меня разоблачили.
Anton Belonogov написал: По обращению 1 мы производим анализ проблемы, к сожалению, он еще не завершен.
Цитата
TGB написал: 1) Ошибка в стандартной функции tosting, в режиме использования Lua в нескольких потоках (как это делается сейчас в QLua), обнаруженная Старателем;
nikolz написал: LUA_API const char *lua_tolstring (lua_State *L, int idx, size_t *len) .......... что не так?
Это не стандартная функция tostring, которая используется внутри Lua, а функция из C-API (файл lapi.c), которая используется программами пользователя, написанными на C++ при взаимодействии с Lua. Стандартная tostring описана в файле lbaselib.c (lua 5.4). Вот список стандартных базовых функций:
А вот код функции luaB_tostring, который реализует "tostring" и в которой вызывается luaL_tolstring(L, 1, NULL):
Код
static int luaB_tostring (lua_State *L) {
luaL_checkany(L, 1);
luaL_tolstring(L, 1, NULL);
return 1;
}
// ------- Вызывается в luaB_tostring (lua_State *L) --
LUALIB_API const char *luaL_tolstring (lua_State *L, int idx, size_t *len) {
idx = lua_absindex(L,idx);
if (luaL_callmeta(L, idx, "__tostring")) { /* metafield? */
if (!lua_isstring(L, -1))
luaL_error(L, "'__tostring' must return a string");
}
else {
switch (lua_type(L, idx)) {
case LUA_TNUMBER: {
if (lua_isinteger(L, idx))
lua_pushfstring(L, "%I", (LUAI_UACINT)lua_tointeger(L, idx));
else
lua_pushfstring(L, "%f", (LUAI_UACNUMBER)lua_tonumber(L, idx));
break;
}
case LUA_TSTRING:
lua_pushvalue(L, idx);
break;
case LUA_TBOOLEAN:
lua_pushstring(L, (lua_toboolean(L, idx) ? "true" : "false"));
break;
case LUA_TNIL:
lua_pushliteral(L, "nil");
break;
default: {
int tt = luaL_getmetafield(L, idx, "__name"); /* try name */
const char *kind = (tt == LUA_TSTRING) ? lua_tostring(L, -1) :
luaL_typename(L, idx);
lua_pushfstring(L, "%s: %p", kind, lua_topointer(L, idx));
if (tt != LUA_TNIL)
lua_remove(L, -2); /* remove '__name' */
break;
}
}
}
return lua_tolstring(L, -1, len);
}
Ну и так далее. ------- Когда вы пишите, например, в скрипте tolstring (5), то используется luaB_tostring. Эта же функция используется неявно Lua для преобразования числа 1 в строку, если вы написали: "текст " .. 1 .
Anton Belonogov написал: По обращению 1 мы производим анализ проблемы, к сожалению, он еще не завершен.
Описав в своем комментарии, в чем, по моему мнению, заключается ошибка использования существующей функции tostring в QLua, я не привел решения по ее ее устранения. Приведу в данном комментарии один из вариантов решения: 1) В начале функции tostring вставить lua_lock(L); 2) В конце всех завершений функции вставить lua_unlock(L).
Anton Belonogov написал: По обращению 1 мы производим анализ проблемы, к сожалению, он еще не завершен. Как только результат будет получен, мы поделимся с Вами информацией.
Если есть конкретные вопросы по моему тексту, то я попытаюсь ответить.
nikolz написал: Вы почему-то опускаете тот момент, что синхронизация нужна лишь при изменении потоками общих данных . т е если данные лишь читаются, то синхронизация обращения к ним потков не требуется.
Цитата
nikolz написал: При своем запуске, GC "ползает" по всем стекам
и при этом изменяет их данные. Возможно , вам известно, что сборка мусора это нетривиальная задача даже при реализации ее в однопоточном варианте. Например, в C# для программы допускается работа в нескольких потоках, но Microsoft, с ее немалыми ресурсами, не смогла реализовать потокобезопасный сборщик мусора и при его работе "замораживает" выполнение потоков. То что делается в QLua, я описал в своем комментарии.
Anton Belonogov написал: Приведите, пожалуйста, ссылки на упоминаемые Вами обращения, проверим информацию.
Здравствуйте.
Цитата
TGB написал: 1) Ошибка в стандартной функции tosting, в режиме использования Lua в нескольких потоках (как это делается сейчас в QLua), обнаруженная Старателем;
TGB написал: 3) Существующая ошибка в QLua версиии 5.3, которую разработчик не собирается устранять, неофициально отказываясь от ее поддержки (заявляя это, втихомолку , в данном форуме), Причем, что характерно, бесперспективно , мною предложен конкретный простой тест для анализа этой ошибки.
Anton Belonogov написал: Действительно, при вызове getDepo из Lua-скрипта из-за синхронизационных проблем могут возникать ошибки.
Что характерно, вы появились вскоре, после того, как на форуме исчез известный пользователь Anton. В любом случае, для поддержки, это правильное решение .
Anton Belonogov написал: проблема изучается. Постараемся в ближайшее время дать ответ.
Проверил у себя в "песочнице" (QUIK версия последняя 10.1). Ситуация возникает постоянно. По всем признакам (возникает в разное время, сообщение не lua) ошибка синхронизации в QUIK.
nikolz написал: Локальные стеки у луа машин майн и основного потока разные и следовательно синхронизация потоков при обращении к ним не требуется и нет блокировки.
Это было бы верно, если бы в Qlua не было общего ресурса потоков: сборки мусора (GC). При своем запуске, GC "ползает" по всем стекам и не является потокобезопасным. Поэтому для всех потоков QLua все фрагменты скрипта, за исключением, вызываемых С- функций, являются разделяемым ресурсом (потоки синхронизируются). Нет синхронизации потоков только при выполнении C-функций, вызванных в скрипте.
! Для поддержки QUIK: 1. Вы зря игнорируете замечания пользователей. Конструктивные замечания пользователей и их учет разработчиком QUIK облегчат вам работу (но грозит последующими уволь-нениями ). 2. В QLua можно, условно, выделить два уровня: 1) системный (обеспечивающий исполнение скриптов пользователей); 2) прикладной (обеспечивающий команды управления QUIK, например, работу с табли-цами QUIK – и это, точно, не таблицы Lua ). В данном комментарии я не буду обсуждать прикладной уровень. Там, до сих пор, много ошибок и это демонстрируют многие комментарии данного форума. На системном уровне, так как я это вижу (ошибок может быть, наверное, и больше), в текущий момент, на 25.01.23, в QLua есть следующие ошибки: 1) Ошибка в стандартной функции tosting, в режиме использования Lua в нескольких потоках (как это делается сейчас в QLua), обнаруженная Старателем; 2) Системная ошибка взаимоблокировки (выполнением «чистого кода Lua») потока main и основ-ного потока QUIK, реализующего колбеки (об этом я в этом форуме много писал). В конце, концов я снял свое предложение по устранению данной ошибки, с пониманием того, что в QLua версии >= 5.4 для разработчика QLua, это неразрешимая задача . 3) Существующая ошибка в QLua версиии 5.3, которую разработчик не собирается устранять, неофициально отказываясь от ее поддержки (заявляя это, втихомолку , в данном форуме), Причем, что характерно, бесперспективно , мною предложен конкретный простой тест для анализа этой ошибки.
nikolz написал: _sk_ ,вот Ваш тест с исправленными Вашими ошибками. Работает без проблем.
Вы до сих пор не поняли, что у _sk_ нет проблем со скритом ( он делает flag = true и все у него хорошо ). Его интерисует странное поведение скрипта когда flag =false и это нормально. Вообще, из того что видно невооруженным взглядом, у вас постоянный зуд отметиться на форуме (как у собачки, выпущенной на прогулку ). Зачем вы работаете на форуме «прокладкой» между комментариями? Явно, что у вас проблемы с вашими комплексами и вы пытаетесь здесь их скомпенсировать. Но вы до сих пор не научились выделять фрагменты текстов комментариев, которые вы цитируете. Вас можно пожалеть (девочки точно не любят), но вы постоянно спамите на форуме и скоро переполните его базу . Меня это беспокоит и только поэтому я на вас реагирую .
_sk_ написал: Я видел Ваши предложения по этому поводу, на которые разработчики, к сожалению, не реагируют.
Для QLua 5.3 есть простое и эффективное решение, которое я протестировал. Но это решение не подходит к Qlua 5.4 так как там было существенно изменено управление памятью и с этим я разбираться не стал. Разработчик QUIK (через поддержку) заявил, что будет поддерживаться только QLua 5.4. Поэтому свои предложения я снял, опасаясь того, что их реализация разработчиком в QLua 5.4. может оказаться некорректной и последствия могут оказаться более неприятными чем то, что есть сейчас.
nikolz написал: Предположу, что это ошибка автора скрипта, так как в нем не учитывается многопоточность.
Филосов . Укажите конкретно в чем ошибка автора. --- Ошибки автора нет. Есть ошибка в QUIK, состоящая в том, что длинные участки фрагментов кода скрипта на "чистом Lua" (без вызова C-функций) блокируют переключение потоков обслуживающего колбеки и выполняющего main. Я не буду повторять свои комментарии по этому поводу. Читайте форум.
_sk_ написал: Тут с OnStop какая-то проблема, как мне кажется.
Причину я описал в своем комментарии. В вашем скрипте эта причина проявляется следующим образом. В цикле функции main есть два фрагмента кода с вызовами C-функций. Это sleep(0) и косвенно вызываемые (с помощью функции run()) стандартные функции работы с таблицами QUIK. При отключении sleep(0) остаются C-функции работы с таблицами QUIK. Поэтому OnStop запускается в потоке обработки колбеков (с выдачей сообщения "OnStop executed"). Но далее запускается pcall(closeWindow). В функции closeWindow отключается фрагмент работы с таблицами QUIK. Исполняемый код цикла функции main при этом представляет код на "чистом Lua". Внутри исполнения pcall(closeWindow) существует вызов C-функции (я с этим уже разбираться не буду), при котором блокируется поток обработки колбеков, но отпускается поток main, где в цикле выполнения кода на "чистом Lua" блокируется поток выполняемый функцию OnStop. QUIK виснет.
_sk_ написал: 2) Знает ли кто-то причину такого поведения?
Проверил у себя в песочнице 10.1. Ваш скрипт зависает при flag = false. Как известно, длинный участок фрагмента кода скрипта на "чистом Lua" в main (без вызова C-функций) блокирует выполнение потока обслуживающего колбеки. Функция sleep(0) - это C-функция. Когда вы исключаете ее исполнение (в цикле), то получается бесконечный фрагмент скрипта на "чистом Lua" и OnStop, являющийся колбеком не может быть выполненным.
Даниил Волошин написал: К сожалению, по присланным данным нам не удалось установить причину ошибки.Мы продолжаем изучение вопроса по Вашему обращению. Как только работы будут завершены, мы отправим Вам соответствующее уведомление.Приносим извинения за причиненные неудобства.
Разработчики QUIK читали мой комментарий: https://forum.quik.ru/messages/forum10/message64871/topic5823/#message64871 ? В нем детально описано: функция tonumber для случая многопоточного использования Lua, как это делается в QUIK, реализована некорректно. Что в моем комментарии непонятно разработчикам QUIK?
Владимир написал: Я не нашёл тип данных integer ВООБЩЕ! И как же мне работать с битовыми масками? Как на Lua реализуется конструкция вида:if (iData & 0x80) { blah-blah-blah }?
Элементарно, "Ватсон" . Пример:
Код
local a =129.0
if (math.tointeger(a) & 0x80) == 128 then --- 0x80 это 128 в десятичном исчислении
message ("С битами можно работать.")
end
Вообще говоря, модель случайных процессов не подходит к поведению фондового рынка. Это вам не безликие физические процессы. Здесь бы больше подошла модель толпы, жаждущей получить прибыль (рождение и падения фондовых рекурсивных, неустойчивых «пирамид»). Но сносной модели такой толпы пока не построено и, скорее всего, построено не будет. Поэтому (на без рыбье и рак рыба) участники фондового рынка вынуждены использовать стохастику на различных индикаторах, добавляя поиски корреляции с экономическими, политическими событиями, и, почти единственный, но расплывчатый закон: если есть большой рост (какой??), то можно ожидать падение, а если падение (какое??), то есть шансы на рост. Причем, поведение рынков со временем меняется, так как меняется среда, в которой они существуют (в том числе меняются и ее участники). Какие индикаторы рынка лучше, спор бессмысленный вне контекста их использования в торговых стратегиях. А единственным критерием качества торговой стратегии (возможно меняющейся со временем) и полезности ее индикаторов является реальная прибыль автора стратегии. В том, что можно «выжать» из истории цен торгов, скорее всего, существует некий предел полезной информации, который невозможно преодолеть никакими вычислительными мощностями и который наступает достаточно быстро.
Владимир написал: Я отказался от всех дебаггеров ещё лет 40 назад, по той простой причине, что они сами глючат.
Действительно, для быстрой отладки, в подавляющих случаях, требуются мозги и продуманная отладочная печать, порождаемая ими. Но, "40 назад" это слабый аргумент. Средства отладки это сложные программы, в которых может быть много ошибок. Но 40 лет большой срок, и за это время появились, отлаженные многочисленными пользователями, достаточно приличные средства отладки. В этом я убедился, когда пришлось привлекать отладочные средства (редкий для меня случай) для анализа ситуации в многопоточной программе на C#.
TGB TGB написал: Если написанное мною в комментарии #177 правильное, то причина понятна и понятно как ее можно исправить. Пусть разработчик QUIK объяснит, в чем я ошибаюсь. Alexey Danin написал: пасибо, передали информацию разработчикам. ------ TGB написал: Долгое молчание: знак согласия с тем что я написал (дважды)?
У меня вопрос к поддержке (простой, но, скорее всего, риторический). У каждого приличного IT-разработчика, как правило, существует в поддержке инструкция по работе с пользователями. Надеюсь что такая есть у ARQA и она не секретная. Мне хотелось бы на нее посмотреть. Как это можно сделать?
Андрей написал: Может кто-нибудь подсказать или ткнуть в раздел документации где про этом можно почитать?
Код варианта реализации таймера:
Код
------------- #### !! Вариант реализации таймерных событий ----
function OnStop()
isRun=false
end;
local function f1(i) -- функция обработки таймерных событий ---
message("Обрабатываем интервал 1: "..i.." сек")
end;
local function f2(i)
message("Обрабатываем интервал 2: "..i.." сек")
end;
local function f3(i)
message("Обрабатываем интервал 3: "..i.." сек")
end;
isRun=true;
function main()
local x
---- !! Таймеры задаются в виде таблицы {<Интервал таймера (в секундах) >, <Функция обработки таймера>, <Вычисляемое время запуска функции>}
t={{4, f1, 0}, {17, f2, 0},{35, f3, 0} } -- Начальный запуск таймера можно задать в третьем элементе таймера. Можно добавлять таймеров сколько надо --
x=os.time()
for i=1,#t do t[i][3] = x + t[i][1] end
message("Начало работы")
while isRun do
x=os.time()
for i=1,#t do
if x >= t[i][3] then
t[i][3] = x + t[i][1] --- !! Если существенна обработка пропущенных интервалов, то:t [i][3] = t [i][3] + t[i][1] ----
t[i][2] ( t[i][1] )
end
end
sleep(100) -- разрешение таймера млсек. ---
end
end
Относительно nikolz у меня существовали разные гипотезы (в том числе и то, что это человек), но я все более склоняюсь, что это полу-интеллектуальный бот-спамер . Что удивительно так это то, что он иногда, редкими местами, пишет вразумительные вещи. Слава создателю этого бота . Я бы не стал его комментировать, но он часто выкладывает тексты, вносящие смуту в неокрепшие умы: типа его сентенции в сообщении #181. Конечно, каждый читающий сообщения, наверное, определит сам, где туфта, но, как представляется мне, этот бот постоянно производит информационный мусор (возможно, со злонамеренной целью переполнения базы форума ).
nikolz написал: У меня например более 20 патентов, а как с этим у Вас?
С этого места, пожалуйста поподробнее. Выложите список своих патентов с их кратким описанием и с указанием всех реквизитов, обеспечивающих проверку их существования.