Вопросы Разработчикам Скриптов, вопросы по скриптам (мелкие вопросы)

хм, кроме пробегания циклом по таблице, особо вариантов нет!

А что если задуматься о кешировании? Допустип так же добавляем метатаблицу с функцией добавления в таблицу, а там уже увеличиваем счетчик, доступ к нему можно так же сделать по вызову функции таблицы tTable(), вот вам идея без пробега по всей таблице.

Так можно сделать, однако, цеплять к каждой таблице метатаблицу не очень удобно.

Причём тут надо учитывать ещё и то, что таблицы в lua передаются по ссылке, поэтому для разных таблиц нужно будет писать разные метатаблицы.

Пример реализации двух одинаковых один в один метатаблиц:

Тест:

Поэтому легче будет пробежать 1 раз по всей таблице, ничего страшного в этом нет.

Типа

И вот еще интересно будет ли быстрее так:

Проверил: 2 функция проигрывает по времени в 2 раза при 100000 записях в таблице...

Nickolya
А как считаешь время отработки задачи, научи? ;) Я пробовал с помощью os.clock() - сходу ничего не получилось. Получается сравнивать только задачи, которые выполняются дольше, чем 1 секунда.

Вот тут был затронут вопрос о таймерах и счетчиках, в начале мая. Наконец дошли руки, обкатал модель реализации срабатывания разных функций по таймеру с разной периодичностью. Глобальный счет считает себе и считает, вперед к победе коммунизма, а каждая из трех функций срабатывает строго по заданному периоду, один раз в 15, 40 и 65 секунд (в примере).
Может, кому-нибудь пригодится.

Быстрота выполнения определяется в процессе дебага кода.

По поводу таймеров для api1, есть более оптимальные методы (см. как это реализовано в хуббе)

"Упс", как говорится. Не добрался до Хуббы, но спасибо Berkut'у, для кого-то изложившему в чате принцип мультитаймера для API1, понял что перемудрил и изменил свой мультитаймер. Не зря говорят - грамотно сформулированная задача это полдела.
Например вот так :



Еще есть ВОПРОС.
Есть центральный модуль, есть подчиненный. У подчиненного модуля есть таблица local tWorkTable и таблица-интерфейс со значениями настроек модуля tSettings, вызываемая центральным модулем при запуске. Задача - по определенной команде вытаскивать изменяемую во времени локальную рабочую таблицу подчиненного модуля (tWorkTable), чтобы сохранять ее или производить над ней другие операции.
Пока что это делается так :

В центральном модуле получаю таблицу из подчиненного модуля так :



при этом в подчиненном модуле вот такая вот ситуация :



Как бы это сделать проще и элегантнее? Чувствую что можно, а как именно - пока тупик.

Хехе. Действительно накрутил слишком заумно как-то))))

Главный модуль:

Подчинённый модуль:

Однако, из-за того, что таблицы в lua передаются по ссылке, а не по значения, то доступ к записи в таблицу tWorkTable будет доступен в обоих модулях. А ты, я так понимаю, хотел реализовать некий принцип инкапсуляции

Дело в том, что модулей несколько, и у каждого своя локальная таблица tWorkTable, причем строение этих таблиц неодинаковое. А хотелось сохранить локальность таблиц подчиненных модулей и стандартное имя tWorkTable, при обработке этих таблиц разными циклами, разными командами. Собственно сами эти циклы в еще одном модуле находятся, который как бы универсален для всех этих tWorkTable, принадлежащих модулям, и предназначен для их обслуживания : автоочистки по опр. признаку, автосохранения, сортировки и т д.
А эти циклы универсального модуля запускаются из главного ( центрального ) модуля, вот такая вот ситуация. Таблица tSettings каждого подчиненного модуля, которая вызывается в центральный модуль при старте скрипта, хранит индивидуальные параметры этих таблиц и задачи для циклов (вызываемые с помощью loadstring). Вот как-то так...

Проще было бы воспользоваться ООП. Тут как раз отдельный модуль - это один объект.

Я не понимаю в чём проблема?
Напиши в каждом модуле свою функцию ActualTable_mod1(), ActualTable_mod2() и тд.

Или как вариант возвращать ссылку на данные при подключении модуля

Главный модуль:

Подчинённый модуль (mod1.lua):

Setuper

Так оно и есть, в каждом модуле своя функция, которая возвращает актуальную (висящую в ОЗУ, и необязательно сохраненную на диск) рабочую таблицу. А проблема вот в чем : нужно, чтобы значение таблицы-интерфейса tSettings.GetActualTable было увязано, т е включало все необходимые сведения для вызова соответствующей актуальной таблицы. Опять-таки, это в принципе и реализовано ( через loadstring и хранение этого самого стринга в tSettings.GetActualTable), а вопрос был - можно ли это сделать проще и элегантнее. Пробовал вместо loadstring хранить в поле tSettings.GetActualTable функцию вроде - не прошло.Разные другие варианты пробовал, ни один не прошел, поэтому обратился за помощью.
Вот про require не совсем понял. Ты писал вот что:

Изменения в файле ( рабочей таблице) - происходят, по ходу деятельности скрипта, т е таблица иногда изменяется, иногда сохраняется на диск, поэтому метод вызова везде dofile.
Или что имелось в виду под "изменениями в этом файле"? Хорошо бы поподробнее, или ссылку на доходчивый и развернутый материал по теме.

Изменения именно в файле - вот что имелось ввиду. То есть за всё время работы скрипта функция require загрузить в память код только 1 раз, при последующих обращениях во время работы скрипта к данной функции она будет брать уже загруженный код.

Вчера начал потихоньку пробовать работать с метатаблицами. Получается вот что. В каком-то подчиненном модуле создается таблица-интерфейс с настройками, и на основании этих настроек создается метатаблица для этой таблицы, с функциями. (если я правильно понял, внутри одной таблицы нельзя для второго элемента-функции использовать переменную, записанную в первом элементе - например если в первом элементе таблицы tTable записано , то во второй нельзя записать . Или все-таки можно?)
Потом таблица-интерфейс вызывается в центральный модуль. Таким образом, центральный модуль имеет не только полную информацию о настройках подчиненного модуля, но и перечень функций, которые нужно по заданному в этих настройках алгоритму применять к! вот тут самое важное. Получается так, что рабочая таблица с какими-то изменяемыми во времени и иногда сохраняемыми на диск данными, элементарно вызывается для обработки в центральный модуль не по имени, и не по чему-то другому, а способом
???
Если это мне не кажется, то это же просто волшебная черная магия, о которой даже и помыслить не смелось
Тогда все предыдущие вопросы с необходимостью использования loadstring - снимаются...
Получается, что вызвать рабочую таблицу модуля можно когда угодно и куда угодно, не используя ее имя, и вне зависимости от изменений, происходящих в этой таблице. Получается принцип, который в радиоэлектронике называют "гальванической развязкой" и который реализован в таком простом и нужном приборе, как "оптопара" ( светодиод-фотодиод или светодиод-фоторезистор).
Так ли это? Не сон ли это??

... и еще прицепом небольшой вопрос. В центральном модуле есть набор констант, строки с типовыми выражениями вроде "$UserCommand 1 3" и т п
Имеет ли смысл создавать в каждом модуле аналогичный набор локальных констант, или все, что можно взять с центрального модуля, пусть периферийные модули от него и получают?

Ты явно изобретаешь велосипед))) Проще воспользоваться ООП. Возможно я не совсем понимаю что ты хочешь сделать, но уж больно это похоже на ООП.

Первый вопрос, ответ - можно (даже без классов):

Вопрос два, ответ - это действительно так. Метатаблица - это отдельная таблица, которую мы подключаем к другой таблице, то есть метатаблица и таблица занимают различные адреса в памяти.

Чтобы ответить на "прицеп", нужно иметь понятие о том, что ты хочешь реализовать.

Ладно)) Не все сразу. Даст Бог доделаю и выложу, тогда, может быть, если будет на то желание и время, можно будет предметно посмотреть.
Второй пункт - самый существенный. Если раньше приходилось по рабоче-крестьянски - вызывать требуемую таблицу строго по имени, то теперь: есть пять модулей, в каждом из них таблица с одинаковым ничего не выражающим именем tInterFace. К каждой такой таблице прикреплена метатаблица с еще менее что-либо выражающим стандартным именем tMetaInterFace, и полем .tWorkTable, которое равно существующей в каждом из пяти модулей рабочей таблице tWorkTable. И вот, О ЧУДО ! в центральном модуле в нужный момент, непонятно по какому признаку и принципу, через непонятно какие третьи руки, возникает и попадает в обработку именно та таблица, которая требуется ))))

По первому вопросу.
Перепроверил еще раз, попробовал запустить такой код :


Результат :lua:4: attempt to index global 'tTable' (a nil value)
Значит, все верно : в одной таблице не могут уживаться условие, и функция, которая выполняется или не выполняется следуя этому условию. Поэтому условия (настройки) храним в локальной таблице, а функции, которые должны выполняться или не выполняться по этим условиям, храним в метатаблице. Так получается? Или какая тут ошибка?
И что значит в приведенном выше примере загадочное слово self ? До сих пор в неведении.

self - это и есть tTable, но в неявном виде.
Только вместо функции надо вызывать метод. Вот так будет работать:


Когда мы пишем tTable:Func(), то это равносильно записи tTable.Func(tTable). Теперь должно быть понятно, что в качестве параметра self в методе выступает таблица.

Можно пойти намного дальше и реализовать так называемый "принцип полиморфизма":
Вот последний пример это уже некое подобие полиморфизма в ООП.

Ясно )) ( пробовал кстати сразу и с self аргументом, нечто подобное интуитивно предполагая, но что-то где-то проглядел, и не запустилось).
Но все-таки думаю пока разделить настройки и функции , хотя теперь вижу, что теоретически можно и в одну таблицу все упихать.

Всем привет! Давно меня тут не было!!! Пардон за оффтоп...вопрос срочный возник...! Есть идеи как (и чем) можно закрыть доступ к TCP подключениям (ну или вообще всем подключениям) по mac ?

Вот наконец пора решать еще один давно интересующий вопрос.
Есть набор функций ( собранных в таблицу), с однотипными именами, различающимися цифрой : Rule1, Rule2 и т.д. Как организовать цикл отработки всех функций по порядку?

тут не подходит :


... и еще вопросик. Нужно записать построчно файл, каждая строка строка должна заканчиваться символом LF (line feed, код 10 ).
"\r" - дает CR (carriage return, возврат каретки, как я понимаю)
"\n" - дает CR LF
string.char(10) - тоже CR LF
Как быть?

1)

2)