eu_tomat

Готово.

Переведу на русский: защита от дурака. О чём я и сделал предположение выше.

Обязательно. Без machine.lua даже EEPROM не запустится.

Вопрос "зачем" подразумевает ответ о целях, намерениях. Какие цели преследовали разработчики, реализуя именно такую механику, вряд ли кто-то может уверенно ответить кроме них самих. Но мы можем пофантазировать. Так как результат выполнения метода makeReadonly является необратимым, имеет смысл сделать "защиту от дурака". Если программист всё-таки смог правильно выполнить этот метод, значит он почитал документацию и ознакомился с последствиями. Эта цель мне представляется наиболее вероятной.

У меня есть идея, но она ломает изначальный замысел. С точки зрения пользователя я бы предпочёл использовать стандартный синтаксис Lua, и чтобы все необходимые сокращения кода за меня выполняла программа. Получилось бы подобие упаковщика кода в последовательность ASCII-символов, которые можно было бы ввести через наковальню.

Надо же, оказывается, существует бюджет и для прямых вызовов! Похоже, что значение бюджета вызовов 232 является чисто номинальным. По факту тяжело сделать даже 216 вызовов computer.uptime за такт. При том, что это сравнительно дешёвый вызов. То есть, совершая прямые вызовы, мы упираемся не в бюджет вызовов, а в производительность, условно говоря, процессора.

Что происходит в этой теме? Автор вопроса сообщает о странной работе метода robot.use, но отказывается называть версию мода. Комментатор рассказывает очевидные вещи, при этом совершенно не проясняя суть вопроса. У кого ещё метод robot.use ставит блок не только из слота инструмента, но также из слота инвентаря? В какой версии мода это проявляется?

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

Симпатичные скриншотики. Синих символов на красном фоне нам очень не хватало в стандартном редакторе. ГЛАЗА!!!

Отнюдь. Оченьжданчик и долгожданчик.

В тот момент, когда я писал сообщение, то именно библиотеку я не смог найти в репозитории. Теперь вижу. Это уже второй вопрос. Без кода эта тема была бы ещё менее интересной и менее полезной. Конечно, программы для ComputerCraft сейчас не пользуются большой популярностью, т.к. этому моду тяжело конкурировать с OpenComputers, но иногда люди ищут программы именно для ComputerCraft. Например, в этой теме просили переписать старую программу. Кстати, в ней почти весь код задействован для отрисовки графики. Может быть, твоя библиотека кого-нибудь вдохновит переписать эту штуку. Благодарю. Так уже веселее.

Так я и не предлагаю заказывать уборку во время формирования кадра. Смысл именно в том, чтобы освободить максимум памяти, занятой предыдущими кадрами. Это позволит начать формировать очередной кадр, имея максимум памяти. То есть, каждый кадр будет формироваться в одинаковых по доступной памяти условиях. Я имел в виду немного другое. После того как ты уже установил память в свой компьютер и оставил его работать, а не просто тестироваться, то можешь заранее вычислить, что файл определённого размера и формата не может быть обработан с имеющимся объёмом памяти. В этом случае нет смысла дожидаться его загрузки, надо запрашивать другой файл. Тесты тестами, но вдруг используемый тобой сервис преподнесёт тебе сюрприз и выдаст ссылку на файл ещё большего размера, чем ты ожидал? Но предварительный анализ позволит твоей программе даже не скачивать картинки, которые она не способна переварить.

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

Для начала я бы предпочёл применить самые доступные способы. Получается 2.48 планки памяти. То есть, можно справиться даже тремя планками из четырёх возможных, если использовать серверный корпус вместо обычного. Заказ уборки мусора после каждой попытки отображения очередной картинки позволит поддерживать максимальный запас свободной памяти. Быстрый отказ от получения слишком больших картинок поможет программе не допускать нехватки памяти, если сервер решил отдать неожиданного крупный файл. По возможности следует ориентироваться по данным HTTP-заголовка. Но в крайнем случае можно и просто контролировать потребление памяти при получении очередного фрагмента данных. Оборачивание критичных вызовов в pcall позволяет обработать в том числе и ошибки, связанные с нехваткой памяти. Главное в этом случае — как можно скорее заказать уборку мусора. Но до этого желательно вообще не доводить. Для лучшей оценки потребности в памяти имеет смысл записывать в журнал её потребление в конце каждого цикла вывода картинки непосредственно перед уборкой мусора. Учитывая, что картинки обновляются не часто, журналирование не будет сильно нагружать систему. Я бы записывал в журнал объём использованной памяти после каждого успешного вывода картинки, а также все опасные ситуации, которые удалось обработать: неожиданно крупные файлы, отдаваемые сервером картинок; ошибки, перехваченные с помощью pcall. Возможно, имеет смысл журналировать и случаи, когда объём свободной памяти опустился ниже установленного лимита, который программист определил как резервный.

А как шесть планок-то впихнуть в компьютер? Насколько я помню, четыре планки являются максимумом. Upd: И ещё вопрос. Чересстрочная гребёнка была и на оригинальном изображении? Либо появилась в результате преобразований?

Как интересно порой читать старые обсуждения! Сейчас @ProgramCrafter лайкнул мой старый комментарий, и я решил посмотреть, что же его так впечатлило. А сейчас я прочитал, и сам проникся. Да! Мы-таки нашли подход к новой механике геосканера. И не хуже прежнего. Это оказалось правдой. Вычисление погрешности геосканера Методика ускоренного вычисления константы шума геосканера Оккультные практики при поиске руды Этот подход конечно, не доведён до кристальной ясности, но он уже сейчас позволяет на порядок уменьшить количество сканирований и при этом полностью отделить полезный сигнал от шума независимо от расстояния. Я, когда писал свой старый пост, даже не мечтал о таком. Вот она, мощь коллективного исследования!

Скрипты — это хорошо. Но как получить код самой библиотеки? Этот раздел предназначен для публикации программ. А отчёт по их разработке может быть лишь дополнением. Поэтому я предлагаю добавить ссылку на код библиотеки или перенести тему в более подходящий раздел. Идеи использования шрифтов Брайля или двойной буферизации уже давно не являются новыми, и поэтому сейчас вряд ли кому-то интересно их теоретическое обсуждение. Но сама реализация может заинтересовать форумчан, даже не смотря на значительно большую популярность OpenComputers в сравнении с ComputerCraft.

Может. Например, если программа управляет ядерным реактором, то взорвав его, она портит всё: медь, олово, железо. А некогда железные нервы игроков вообще не подлежат восстановлению.

Не обязательно дичь, если говорить о красной плате в вагонетке. Возможно, так оно и было задумано. Я тогда надеялся научить вагонетку самостоятельно переключать железнодорожные стрелки красным сигналом самой вагонетки. Это было бы интересно. С другой стороны, я понимаю, что источник красного сигнала, летящий на скорости 20 блоков в секунду, может быть плохо совместимым с уже существующими механиками. Майнкрафт является детской игрой, а детские интересы в большинстве своём примитивны. Это нормально. Поэтому взрослые бородатые дяди готовы и к дичи и трешу, осознавая, что для переоборудования детской площадки под свои интересы требуются силы, время и рассудительность. Как пели персонажи известной сказки: нам не страшен детский треш.

В любом случае эта проблема не решается перемещением программы в каталог /usr/bin. Значит, с этой точки зрения такое решение тоже нельзя назвать более правильным. По этому критерию оно равнозначно выбранному автором программы. Одним из удобств OpenOS является возможность работы, не покидая домашнего каталога. Все файлы, не имеющие отношения к операционной системе, могут находиться в каталоге /home. Пользователю обычно требуются очень веские основания для перехода в другой каталог. В этом случае пользователь знает что делает, и с какой целью. А если пользователю хватило ума не только перейти в другой каталог, но и вручную указать путь к программе, то его действие точно не случайно. И если пользователь решил, что файл paint.dat должен быть записан именно в этот каталог, то так тому и быть. О том и речь: это зависит от конкретной OS. OpenOS не навязывает структуру каталогов ни пользователям, ни программистам, что добавляет ей очков популярности. Программисты могут писать код "на коленке", концентрируясь на том, что им интересно в данный момент. Что непростительно во взрослых системах, может быть допустимым в детской OpenOS. Следование канонам здесь опционально, а не обязательно. Я бы понял претензию к тем авторам, которые намеренно засоряют каталоги OS не предназначенными для них файлами. Но смешивать программы и данные в домашнем каталоге — это давняя традиция в использовании OpenOS. Да, это иногда создаёт неудобства, но чаще всего оказывается наоборот — это удобно и понятно пользователю, и при этом необременительно для программиста. Этот аргумент я считаю решающим. Стандарты и каноны должны решать проблемы, а не порождать новые.

Назови причину, по которой перенесённые мной сообщения должны остаться в исходной теме. Кому они адресованы, и какую цель преследуют? Разберу первое из твоих сообщений, которое я перенёс: Сообщения такого рода я считаю кандидатами на удаление. Но, если позволяет время, я на всякий случай стараюсь выяснить, что именно хотел сказать автор. Если автор не даёт чёткого ответа, я удаляю сообщение. Или переношу его в более соответствующее место. В данном случае такое место нашлось. И вот мы здесь. Разберу твоё сообщение по словам. Начну я с самого яркого слова — «задрали». Каков смысл этого слова? Я знаю два наиболее распространённых варианта. Например, дикие звери растерзали тебя или же сильно порвали. Но вряд ли ты вкладывал в это слово именно такой смысл. Иначе мне представляется медведь с охапкой красных маков. Второй распространённый смысл слова «задрали» — причинили сильную боль и страдания. А это уже обвинение. Более того, такое использование слова является новым. По сути это эвфемизм более грубого слова. Но как ты ни смягчай его, смысловой оттенок остаётся грубым. Соответственно, это не просто обвинение, а обвинение в грубой форме. И чтобы в этом не осталось сомнений, ты повторил слово второй раз, усилив эффект. Теперь перейдём к сути обвинения. Тут можно было бы снова представить медведя на поляне, среди цветущих маков, но ты развеял мои сомнения: Всё-таки ты обвинил автора темы в подражании MacOS. Но на каком основании ты предъявляешь претензию? Что лично тебе должен автор? Он дал тебе какое-то обязательство? Максимум, на что ты можешь рассчитывать — попросить автора сделать что-то подобное в более привлекательном для тебя стиле. Попросить, а не обвинить. Соответственно, твоё обвинение не является обоснованным. Необоснованное обвинение в грубой форме я считаю провокацией. Таким сообщениям не место на форуме, и они подлежат удалению. Но если тебе нравится грязь в комментариях, то она более уместна в твоей же теме. Ты же обещал сделать систему с интерфейсом, похожим на Windows? Обещал. При этом автор системы SwiftOS такого обещания не давал. Значит, в какой теме твоё обвинение выглядит более уместным? Конечно, извиняю, но сообщения, явно неадекватные темам, я продолжу либо удалять, либо переносить. Если целью сообщения было донести своё пожелание до автора темы, то рекомендую оформить его именно как просьбу, а не как обвинение.

@alice_fdream Так что же получилось-то в конечном итоге? Презентацию я не видел. А по описанию я так и не смог понять, что это, и зачем оно нужно. Это новая операционная система? Если да, то на чём она основана, и каковы её отличительные черты?

Поддерживаю. Собственно, в эту мысль и упираются все рассуждения о правильности выбора путей в среде OpenComputers. Разверну эту мысль, т.к. кое-кто у нас нас на форуме любит душнить про стандарты ради самих стандартов. Следовать канонам в первую очередь должны разработчики операционных систем или же систем управления пакетами. От этого зависит удобство обслуживания операционной системы. Но у прикладного ПО для OpenComputers имеется специфика: писать программы, не требующие адаптации пользователем, нецелесообразно: и программисту никто не платит за этот дополнительный труд, да и детские компьютеры не особо предназначены для громоздких программ, предусматривающих все возможные варианты выполнения. Поэтому в большинстве случаев пользователь будет вынужден изменять прикладную программу под себя. В этом случае разделение данных, настроек и кода теряет смысл, т.к. только пользователь знает, какой путь для размещения программы более правилен в его конкретной ситуации. Да, в каких-то случаях это имеет смысл. Но автор программы вряд ли предусмотрел такую возможность. Например, обсуждаемая программа пишет файл paint.dat в текущий каталог. В этом случае "вызов из любого места" как раз и может привести к замусориванию файловой системы, против которого выступал @rootmaster.

А чем не красива установка в /home? Чем она не чиста? Что даёт следование канону в данном конкретном случае?

А игроку это что даст? Чем именно оно лучше? В чём преимущество предложенного тобой решения?