Zer0Galaxy

Наложил заплатку

Безусловно эту багульку надо исправить. В следующем релизе будет пофикшено. Нужно потестировать на предмет copy/move, может еще что вылезет. Уже сейчас при копировании/перемещении файла, целевой путь можно редактировать, стоит только при выскакивании окошка Copy file несколько раз нажать backspace и ввести новый путь. Другое дело, это не совсем удобно если нужно переименовать файл, оставив его в прежней директории.Может действительно по shift+F6 сделаю опцию Rename.А вот какие планы у Сангара по включению того или иного ПО в комплект мода, ничего сказать не могу.

Всё дело в том, что переключения между потоками осуществляются по слипам (по computer.pullSignal, если точнее). Слипов нет, и другие потоки управления не получают.

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 И как на счет зоны нечувствительности? Неужели в майнкрафте есть объекты, для регулирования которыми требуется ПИД-регулятор?

В первой реализации мантисса метачисла действительно хранилась в массиве. Но, потом я подумал, что строка, содержащая тоже число, занимает гораздо меньше памяти чем массив и перешел на строки. Может и зря. Конечно, нет. Десятичный вид хранения лишь упрощает функцию 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 – количество вхождений слова в текст (если слово встречается в тексте только один раз, внесение его в словарь не даст эффекта).

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

А если для этого использовать не конкатенацию а функцию gsub? string.gsub("abrakadabra","ab","AB") --> ABrakadABra