Anon

Копаясь среди компонентов и функций, я остановился на eeprom:

Функция makeReadonly зачем-то требует хэш данных, записанных на eeprom. Причем параметр обязательный, и обязательно должен соответствовать хэшу данных на eeprom. Самое смешное, что этот хэш можно получить другой функцией eeprom - getChecksum. Судя по исходникам, ни для чего, кроме проверки в функции makeReadonly этот хэш не используется, но вот если он будет неправильный, то вернётся ошибка. Зачем это вообще было сделано? 

@ProgramCrafter Значит я неправильно понял сообщение об ошибке. Так или иначе, получить полный стектрейс в этом случае не получится.

Надеюсь, проект ещё жив, но на свежую OpenOS ставиться отказывается

В 25.03.2021 в 14:10, Belzebub сказал:

Да как решить то я знаю, вопрос был не об этом.

Вопрос был в корявости комповской stderr, его можно как-то починить?

Нет, нельзя. В стеке вызовов видно, что ошибка происходит в /lib/process.lua. А происходит она, скорее всего, из-за неверного значения переданного в одну из функций библиотек OpenOS аргумента. Судя по всему, стек вызовов настолько большой, что debug.traceback заменила его часть на "(...tail calls...)". Это недоработка разработчиков самого lua, так как во время отладки важно видеть первые вызовы, а не последние.

Вопрос неоднозначный. Как такового файлового потока stderr, по аналогии с реальными машинами, в opencomputers нет. То что вы видите - фактически сообщение об ошибке красного цвета. Если вы хотите самостоятельно обработать ошибку, произошедшую в рантаеме, есть два способа:
Самый простой вариант - pcall

local result, value = pcall (function () --[[ ... ]] end)

Если функция, переданная в pcall первым аргументом, выполнена успешно, первое возвращаемое значение будет true, а все последующие - значения, которые вернула исполняемая функция.

В обратном случае, первым значением pcall вернёт false, а вторым - сообщение об ошибке, которое вам нужно.

Однако, при использовании pcall, вы получите только сообщение об ошибке, но не стек вызовов, который показывает OpenOS.

Другой, более навороченный вариант - xpcall

local function errorHandler (errorMessage)
	print ("Runtime error: " .. errorMessage)
	print (debug.traceback ())
end

local result, value = xpcall (function () --[[ ... ]] end, errorHandler)

Если функция, переданная в xpcall выполнена успешно, то возвращаемые значения будут такие же, как и с pcall.

А если во время выполнения функции произойдёт ошибка, то вторым значением xpcall вернёт то, что вернула функция-обработчик.

То есть xpcall вызывает обработчик, вместо того чтобы просто вернуть ошибку.

Но в чём же профит, спросите вы? Тут есть один занятный момент: обработчик ошибок вызывается именно в том месте, в котором произошла ошибка. А это значит, что debug.traceback, вызванный в обработчике, вернёт стек вызовов актуальный для контекста ошибки.

Хитрым образом эту фичу использовал @ECS в процессе разработки MineCode IDE для реализации брейкпоинтов:

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

Кстати, пожалуй, удобнее всего обрабатывать ошибки так:

local result, value = xpcall (function () --[[ ... ]] end, debug.traceback)
if not result then
  print (value)
end

Поскольку debug.traceback конкатенирует свой аргумент со стеком вызовов.

Рутмастер, попробуй рассуждать логически. Допустим не будет. Почему?

Действительно, робот может использовать содержимое слота инструмента в качестве блока. Почему? По тому что может. Другой вопрос, может ли это помешать корректной работе программ, написанных под робота? Не думаю. Не смотря на то что robot.use может поставить перед собой блок, находящийся в слоте инструмента, функция robot.place всё равно ставит выбранный в инвентаре робота блок. А если выбранный слот пуст, то не поставит, игнорируя содержимое слота инструмента. Так что это скорее фича чем баг, и достаточно просто иметь в виду этот факт.

Можно. Но я не знаю как реализована функция pull_e. Если она использует базовое апи computer, тогда в качестве аргумента computer.pullSignal передайте 0

computer.pullSignal (0)

Если же вы используете библиотеку event из OpenOS, то в event.pull аналогично первым аргументом передайте 0

event.pull (0, eventType)

Однако стоит заметить, что если каждый кадр вы рисуете целиком (очищаете экран, ставите надписи итд), то при таком подходе интерфейс будет, скорее всего, мигать. Хотя это уже другая тема, здесь поможет двойная буферизация.

Иногда удобно использовать встроенное средство редактирования файлов OpenOS.

Однако мне никогда не нравился дефолтный чёрный цвет фона. Поэтому я немного модифицировал edit.lua так, чтобы цвета легко настраивались.

Установка проще, чем заварить чай. Достаточно скопировать и запустить следующую команду (OpenOS должна быть установлена).

wget -f https://raw.githubusercontent.com/Smok1e/oc-openos-colored-edit/main/edit.lua /bin/edit.lua

Настроить цвета можно в стандартном файле конфигурации - /etc/edit.cfg

В конце файла добавьте (или измените) следующее:

colors = {
	background = [желаемый цвет фона],
	foreground = [желаемый цвет текста]
}

Например:

Спасибо за внимание. Кстати если кто-нибудь знает, каким образом можно изменить цвета стандартной оболочки OpenOS, буду признателен, если расскажете.

2 часа назад, num_pi сказал:

. Главное что работает

Типичный сотрудник ubisoft:

5 часов назад, num_pi сказал:

 

Держи готовую функцию. for i = 1, 8 do: здесь поменяй 8, на большее число, если нужно что бы рандомное возвращаемое число было больше. 

function rand()
	local res = ""
	for i = 1, 8 do
		res = res .. string.char(math.random(48, 57))
	end
	return tonumber(res)
end

 

1) Магические числа - быдлокод. Что за 48 и 57? string.byte ('0'), string.byte ('9').
2) Результат будет всегда 8-значный или N-значный
3) math.floor??????
Ну и наконец, math.random возвращает целое число, если в него передать целое значение. math.random (10000000).
О производительности твоего примера я даже боюсь говорить. Вызов string.char в цикле, конкатенация строк, которые в луа иммутабельны просто убьют процессор, если функция будет использоваться часто.

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

Пробовал по аналогии установить окну .onClose, но ничего не происходит.

Я добавил обработчик событий в приложении mineos. После закрытия окна, обработчик продолжает работать, и чтобы этого избежать, мне необходимо удалить его из списка обработчиков системы после закрытия окна. Но я не нашёл способов обработать его, в документации окна сказано только о функциях обратного вызова onResize и onFocus.

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