Zer0Galaxy

Ну вот пример. Мне нужно выводить какое-то значение на экран, которое постоянно изменяется. И параллельно принимать сигнал от event.pull(), чтобы можно было взаимодействовать. Ибо во время вызова этой функции приостанавливается программа.

local thread = require("thread")
-- Инициализируем многозадачность
thread.init()

function foo()
  while true do
    print(какое-то значение)
    os.sleep(1)
  end
end

-- Запускаем функцию в виде параллельного потока
thread.create(foo)

while true do
  e={event.pull()}
  -- что-то там
end

Особенность многопоточности в том, что event.pull и os.sleep притормаживают только тот поток, в котором вызываются. Остальные потоки работают как работали.

А вообще, для данной задачи, многопоточность слишком сложное решение. Лучше использовать event.timer или event.listen, как предлагалось выше.

Обновилась версия МС!

Теперь копировать/перемещать можно не только файлы но и папки!

Слава рекурсии!

Я, похоже, не правильно понял вопрос. О каких функциях идет речь и какие значения они должны возвращать? Если можно, пример кода

В данном случае, основное назначение функции - содержать тело потока, а не возвращать результат. Если очень нужно, результат можно вернуть через глобальную переменную.

Конечно, можно подправить библиотеку и генерировать событие по завершению потока, а параметром события передавать возвращаемое значение.

TraerTaer, давай я сделаю тебе объект-кирпич, ты увидишь насколько это проще и возьмешь меня в соавторы

Захочешь ты сделать кирпич, который не выбивается или выбивается с двух и более касаний, как ты это реализуешь анализируя только цвет экрана?

Подобные игры - идеальный случай изучить ООП.

На мой взгляд платформу лучше двигать не по событию key_down, а начинать движение по key_down и останавливать по key_up. Так движение будет более равномерным.

Рассмотри возможность сделать шарик не пикселем, а полупикселем.

Даешь текстуру кирпичей и платформы.

Ну, и хотелось бы подарки, выпадающие из кирпичей.

Байтика автору

 

PS Я бы кирпичи и платформу сделал объектами и при движении шарика анализировал не цвет экрана, а касание объекта.

Он не даёт никакой прибавки к скорости программирования или уровню оптимизации кода. Абсолютно бесполезная вещь.

Он дает +1 к ЧСВ. У меня, к примеру, благодаря байтикам, ЧСВ близко к переполнению.

... МайнЭкспресс и ФэйсМайном

А это что за звери?

А-а-а! Там остался мой домик из грязи! Как жить дальше? 

В функции loop.reset достаточно сбрасывать только интегратор loop.I. Переменная loop.D все равно пересчитывается на каждом такте регулирования независимо от своего предыдущего значения. А что такое loop.p0 вообще не понял. Она нигде не определяется. По идее где то должно быть

loop.p0=get

И как на счет зоны нечувствительности?

Неужели в майнкрафте есть объекты, для регулирования которыми требуется ПИД-регулятор?

 

 

Хранить числа в виде строки — неэффективно. Куда лучше держать число в массиве чисел. Скорость критична.

 В первой реализации мантисса метачисла действительно хранилась в массиве. Но, потом я подумал, что строка, содержащая тоже число, занимает гораздо меньше памяти чем массив и перешел на строки. Может и зря.

 

 

@Zer0Galaxy, а мантисса обязательно должна храниться в десятичном виде?

Конечно, нет. Десятичный вид хранения лишь упрощает функцию tostring.

Библиотека, приведенная Лешей, действительно на много эффективнее, хоть и работает только с целыми числами. Нужно дополнить ее битовыми операциями и вопрос решен.

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

На сколько я знаю, битовые операции в Луа реализуются при помощи библиотеки bit, а не встроенными методами. Поэтому метаметоды тут не прокатят. Нужно либо перекрывать методы библиотеки либо писать свои функции. Какой из вариантов более приемлем?

Еще бы OpenFTP-сервер...

Не. Просто прибежать в нужную точку и сказать слово в чат - не интересно. Давай так, чтоб программировать нужно было. Ну там, прибежать в нужную точку, отправить по вайфаю строку, получить ответ, преобразовать его должным образом и снова отправить в течении определенного времени, т.е. чтоб преобразование программа делала.

 

 

Ну это типо мигает

Без слипа? У тебя комп вылетит через три секунды 

И всё же я бы не рекомендовал ограничивать исходный текст 128-ю символами. И дело даже не в кириллице. Вот в твоем скринсейвере используется символ "▄". А одного такого символа уже достаточно чтобы архив стал нераспаковываемым.

На счет использования символа 255 в разных кодировках говорить не буду, не изучал. Да и привел его лишь для примера. Не нравится этот, можно выбрать другой. К тому же вхождение символа 255 (или любого другого) в исходный текст не исключает использования его в качестве служебного. Достаточно завести под него слово в словаре. Определяем слово под номером ноль, состоящее из одного символа 255, а в исходном тексте все символы 255 заменяем на комбинацию символов 255+0. Главное, чтобы служебный символ встречался в несжатом тексте не слишком часто.

 

Что же касается дополнительных служебных символов 254 и 253, думаю можно обойтись без них если принять такой формат сжатого файла:

1) длина словаря - 1 байт. Поскольку словарь не может содержать более 256 слов, одного байта будет достаточно.

2) Словарь. Каждое слово в словаре представлено в виде:

    2.1) длина слова - 1 байт (это накладывает ограничение на максимальную длину слова в 256 символов)

    2.2) собственно слово.

Как видим, служебные символы пока не используются, тем не менее такая структура дает возможность однозначно идентифицировать начало и конец каждого слова, а значит и конец словаря в целом.

3) Сжатый текст. Вот тут каждый встреченный служебный символ вместе с последующим за ним должны быть заменены на соответствующее слово из словаря.

Предлагаю для маркирования слова использовать не произвольный символ с кодом >127, а строго определенный символ, который никогда не встречается в lua-тексте или встречается крайне редко, например, символ с кодом 255. Правда, в этом случае слово в тексте будет замещаться не одним байтом, а двумя 255+<номер слова>. Это позволит сжимать тексты с кириллицей к тому же длина словаря увеличивается до 256 слов

Тогда алгоритм сжатия выглядит как-то так:

1. Сoздать пустoй слoварь
2. Найти в тексте слово с максимальным показателем сжатия P
    Если P<1 переход к шагу 3    -- нет слов для сжатия
    Заменить в исхoднoм тексте слoва на симвoл с кодом 255 + символ с кoдoм [длинна_слoваря]
    Внести слoвo в слoварь.
    Если длинна слoваря > 255 переход к шагу 3  -- словарь заполнен
    Иначе переход к шагу 2
3. Присoединить слoварь к тексту.
4. Вернуть текст.

Упомянутый показатель сжатия P показывает как сжимается текст в результате внесения слова в словарь. Очевидно, что он тем больше чем длиннее слово и чем чаще оно встречается в тексте. Показатель сжатия можно оценить как:

P=(L-2)*(N-1)

где L – длина слова (слова длинной <=2 не сжимаются);

N – количество вхождений слова в текст (если слово встречается в тексте только один раз, внесение его в словарь не даст эффекта).

А какая польза от кириллицы в Lua? Как по мне, только вред - кодировка может слететь и файл будет забиваться мусором.

А я вот недавно просматривал код одного автора, так там кириллица совсем не вредит, а очень даже к стати.

 

 

Заменить в исхoднoм тексте слoва на симвoл с кoдoм

А если для этого использовать не конкатенацию а функцию gsub?

string.gsub("abrakadabra","ab","AB") --> ABrakadABra 

 

 

Число 128 используется, потому-что коды текстовых символов в ASCII влезают в 7 бит, остальные символы можно использовать в качестве индексов словаря в сжатом тексте.

А как же кириллица?  Она же >127, или нет?

Я бы не использовал event.listen, а использовал event.pull. По событию "key_down" платформа начинает движение, а по "key_up" останавливается. Не нужно два десятка раз жмакать на клавишу да и с ignore не будет проблем.

Собственно перемещение платформы осуществлять по таймеру. Можно через os.sleep, но тогда нужно использовать многопоточность, что бы движение одной платформы не влияло на другую.

Ну, если говорить строго, данные на экране обновляются не в цикле, а с периодом. Именно для этого и предназначен компонент-таймер (см. пример с computer.energy). Применение таких таймеров реализует своего рода многопоточность ибо работа таймера никак не должна влиять на работу остального кода.

К стати, не рекомендую использовать многопоточность на основе thread совместно с forms. Они могут передраться.