Лидеры

За изобретение велосипеда лайк. А нужный функционал уже реализован утилитой find.lua в OpenOS: find / --name=*find*

Привет, мир! Мой первый пост на этом форуме, и первый скрипт, хоть сколько-то дописанный до конца) Для интереса было решено написать небольшую утилиту поиска. Алгоритм простой: рекурсивно перебирать все файлы, начиная с рабочей директории; если найдено совпадение с запросом - добавить в таблицу результатов. Буду благодарен за любую конструктивную критику) Установка: Код:

Также я выяснил, что максимальный размер считываемого блока для компонента filesystem составляет 2048 байт против 512 для компонента drive. И при использовании максимальных размеров блока скорости чтения filesystem и drive уравниваются. Учитывая это знание, я бы выбирал между filesystem и drive, исходя из оптимального размера блока. Но это справедливо для постоянно открытых файлов. В ином случае к затратам на чтение требуется добавить затраты на открытие и закрытие.

Так при указании корневой директории в качестве стартового пути вся смонтированная файловая система и обходится. В моём примере так и задано.

@eu_tomat , хех) Кроме того, я ещё и не знал про существование shell.resolve

Оставлю здесь результат обсуждения в чате по этим двум постам: Я не учёл того, что размер данных, считываемых с кассеты, ограничен лишь размером доступной оперативной памяти, на что мне указал в чате@ProgramCrafter. Поэтому не смотря на то, что для чтения с кассеты требуется потратить один тик на позиционирование плюс один тик на чтение, итоговая скорость чтения с кассеты может оказаться в десятки раз выше скорости чтения жёсткого диска. Но возможность использовать преимущество чтения огромного блока в конченом счёте будет определяться конкретными условиями. Недостаточный запас свободной оперативной памяти даже если и позволит считать блок данных, не обязательно позволит его использовать, это сильно зависит от используемого алгоритма. Также чтение большого блока данных может оказаться попросту ненужным, так как тот же алгоритм B-tree позволяет обойтись меньшим количеством данных, но находящихся в независимых друг от друга блоках. И про затраты в два тика времени также не стоит забывать. Но я не исключаю, что в каких-то применениях лучшую скорость покажет именно работа с кассетами. Например, Lua позволяет быстро находить фрагменты хешей внутри даже больших строк, что позволит не тратить время и оперативную память на полную расшифровку считанного блока данных.

Оки. Спасибо завтра попробую отпишу.

Дык попробуй отослать MOTD\r\n или MOTD\n, в 90% случаев серваки должны адекватно проинтерпретировать сообщение, если это прям не лютый кастом

Сервер то не мой. Ладно тогда время кастылей)

Сокет-сервак в режиме ресивера работает по накопительному принципу, и сообщения крайне часто будут стоять в буфере друг за дружкой, ожидая обработки, эт нормально. Высокоуровневые библиотеки решают эту проблему через протоколы прикладного уровня по OSI, а ты работаешь с "чистым" сокетом, поэтому придётся минимально пораскинуть мозгами Решений несколько: можно на клиенте перед отсылкой пакета добавлять в начало байт-префикс с длиной содержимого, а на сервере читать накопившийся результат, основываясь на принятых длинах пакетов. Если этот вариант слишком сложен или избыточен (например, если твой софт передает преимущественно короткие сообщения-команды), то можно попросту разделять пакеты любым спец. символом - обычно в сокет-чатах используют символ перевода строки \n

OpenComputers никак не препятствует созданию файлов размером с целый диск или даже RAID-массив.

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