logic

я решил сменить ник на logic, но как поменять его на форуме?

15 минут назад, Bumer_32 сказал:

ну например в Mine OS dev mode нету хотя работа с файлами очень удабна и не мешает

у меня реализация такая, меня все устраивает, надеюсь вопрос по поводу dev mode изчерпан

15 часов назад, Bumer_32 сказал:

кстати м.б действительно одно из хороших вариантов развитий системы была бы поддержка планшетов!

ос поддерживает планшеты

15 часов назад, Bumer_32 сказал:

я бы ещё dev мод выпилил ведь OC ставят для чего? правильно что бы программировать (открываем "новые" возможности форума)

ну.... не очень идея, в dev моде работа с файлами устроенна иначе, что не удобно для простой работы, так что, dev мод с системе будет

В 19.08.2022 в 14:33, daniilFigaSystem сказал:

сделай поддержку 1 уровня монитора

возможно сделаю, но это не скоро

В 09.07.2022 в 15:03, ECS сказал:

Годнотища! Визуально напоминает убунту, даже баклажановый фон в наличии, хех. А какие планы на дальнейшую разработку? Какой прикладной софт поставлен в приоритет на реализацию? Будет ли это исключительно десктопная ОС или же намечена поддержка лоу-тир планшетов?

 

Бтв это хороший пример, когда истинные гигачады молча созидают шедевры, а мелочные нормисы лишь грязнут в полемике на тему "правильности" методов разработки

а почему как лоу-тир так сразу планшет? ведь у компа тоже может быть тир-1/2

1 час назад, ProgramCrafter сказал:

local eeprom = require 'component'.eeprom
eeprom.set''
eeprom.setData''
eeprom.setLabel''
eeprom.makeReadonly(eeprom.getChecksum())

 

положи чип в верстак вместе с рабочим и он заработает)

15 часов назад, hohserg сказал:

Может ли существовать программа для обычного компа, которая портит железо(игровое)?

сомневаюсь, но решил предостеречься, мололи

я помню пару раз ломал sound card подав на нее слишком много команд, после чего из нее кроме грабовой тишины нечего не звучало, и програмно, у меня ее сбросить не получилось, пришлось менять

внимания! автор программы не нечет ответственность за утерянные данные/порчу железа вследствие использования данного ПО, используя данные ПО, только вы сами несете ответственность за свои данные!

скрины:

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

для его установки достаточно из openOS (или что вам больше по душе), перейти в папку где смонтирован жесткий диск, который вы хотите превратить в мульти загрузочный, а зачем запустить команду 

wget https://raw.githubusercontent.com/igorkll/multiBootloader/main/init.lua init.lua -f

все операционные системы необходимо поместить в папку "/operatingSystems/osname", так же необходимо чтобы в корне папки ocname был файл init.lua

теперь вы сможете ставить openOS и plan9k на один жесткий диск

наверное многие этого хотели, но некто там и не сделал что-то подобное, несмотря на то что это довольно просто

о любых багах просьба репортить в тему/мне в лс

17 часов назад, eu_tomat сказал:

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

это да, я это не заметил, я думал что она пишет в etc, или в свой каталог, но такого я даже предположить не мог, но даже если она будет лежать в home некто не мешает вызвать ее из другой папки по полному пути /home/paint.lua

17 часов назад, eu_tomat сказал:

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

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

Только что, eu_tomat сказал:

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

ну.. так как-то покрасившее будет каноничние, и чище, фска будет меняя загаженной)

Только что, eu_tomat сказал:

И что игроку даст её использование?

прожка будет находиться в папочке usr/bin , как по мне, так намного лучше

В 05.08.2022 в 21:02, ProgramCrafter сказал:

Мониторы в OpenComputers поддерживают только текстовый режим, но интерфейс можно сделать круче с помощью символов из Юникода.

До недавних пор символы приходилось выбирать из таблицы (https://computercraft.ru/topic/1962-shrift-v-oc/) и вручную проверять на то, подойдут ли они в интерфейс или иконку. Но сейчас я представляю вам IconPaint - программу, позволяющую интерактивно менять символы внутри иконки и сразу видеть результат!

 

Как скачать:

wget -fq https://github.com/ProgramCrafter/lua-utils/blob/main/paint/paint.lua

Управление такое:

1. стрелки на клавиатуре выбирают редактируемый символ (справа подсвечивается синим),
2. backspace, цифры и буквы a-f служат для редактирования шестнадцатеричного кода символа,
3. клик левой кнопкой мыши по палитре задаст редактируемому символу такой же цвет текста, клик правой - цвет фона,
4. выход по Ctrl-C; проделанная работа сохраняется в файл paint.dat.

 

Пример paint.dat (осторожно, это валидный код на Lua, и при загрузке IconPaint запускает его, хоть и в ограниченном окружении):

data = {
  {0x0020, 0x2580, 0x2580, 0x2580, 0x2580, 0x2580, 0x2580, 0x0020},
  {0x0020, 0x0020, 0xE18B, 0xE146, 0xE147, 0xE18C, 0x0020, 0x0020},
  {0x0020, 0x0020, 0xE18E, 0xE149, 0xE148, 0xE18D, 0x0020, 0x0020},
  {0x0020, 0x2584, 0x2584, 0x2584, 0x2584, 0x2584, 0x2584, 0x0020}
}
overlay = {["2 3"]={16777215,2960685,2,3},["3 3"]={6684927,0,3,3},["4 3"]={16777215,6684927,4,3},["5 3"]={16777215,6684927,5,3},["7 2"]={16777215,2960685,7,2},["7 3"]={0,2960685,7,3},["3 4"]={0,2960685,3,4},["2 4"]={0,2960685,2,4},["5 4"]={0,2960685,5,4},["4 4"]={0,2960685,4,4},["7 4"]={0,2960685,7,4},["6 4"]={0,2960685,6,4},["6 1"]={0,2960685,6,1},["5 1"]={0,2960685,5,1},["4 1"]={0,2960685,4,1},["3 1"]={0,2960685,3,1},["2 1"]={0,2960685,2,1},["5 2"]={16777215,6684927,5,2},["6 2"]={6684927,0,6,2},["3 2"]={6684927,0,3,2},["4 2"]={16777215,6684927,4,2},["2 2"]={16777215,2960685,2,2},["6 3"]={6684927,0,6,3},["7 1"]={0,2960685,7,1}}

Что в планах:

1. расширить зону для редактирования иконки (сейчас 8x4 символа),
2. добавить вставку символов из буфера обмена.

 

Скриншот под спойлером:

  Скрыть содержимое

вот более "правильная" команда для установки: mkdir /usr/bin; wget https://raw.githubusercontent.com/ProgramCrafter/lua-utils/main/paint/paint.lua /usr/bin/paint.lua

В 09.08.2022 в 15:15, alice_fdream сказал:

ВАЖНО! Презентация состоится 13 августа, в 15:00! Radmin VPN Data

26.198.161.75

Имя сети: SwiftOS_Hopper

Пароль: 64396439

Через час тут будет модпак

 

SwiftOS Hopper Beta

 

Аэлита в поиске себя и своего происхождения, нашла загадку своего отца, создателя Лиоко.

 

Что за ключ хранишь же ты,
Почему не хочешь нас спасти?
Убегай скорее в башню,
У него немного шансов.

 

Установка

pastebin run 49Q4SzLV

 

Изменения

Новые приложения, обновлена работа нескольких библиотек, и всего прочего

 

Ссылки
Документация

 

Создатель SwiftOS мудрец Дизайнер мудрец Синий Экран Художница

 

я приду на презентацию, ок? хочу извиниться за наезд в тг

Только что, VBerezin сказал:

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

1. зачем он там?

2. кто будет писать под него программы?

это конечно прикольно

у меня была идея сделать что-то подобное, скрестить mineOS и openOS и назвать это mipoOS, пожалуй, я продолжу этот проект

В 09.08.2022 в 14:49, VBerezin сказал:

Ну смотри. В GUI операционной системе по стоку нельзя запустить терминальные приложения, приходится использовать либо эмулятор OpenOS (ссылка на данный материал), что не совсем удобно: сначала нужно установить это приложение, затем только использовать и настраивать так, чтобы было удобно использовать. В модификации же уже всё настроено: есть как отдельный Shell: можно войти в систему не входя при этом в GUI-режим с экрана блокировки, либо можно зайти в рабочего стола, кликнув по: Система > Перейти в терминал, что упрощает использование. При этом при всём, можно запускать приложения как для родной терминальной платформы (в нашем случае mineCORE - это модифицированный OpenKernel), так и для openOS. Это действительно удобно. Плюсом ко всему, можно использовать терминал и в GUI режиме

ну, в среде mineOS то по любому терминальные апки не запустишь

31 минуту назад, ProgramCrafter сказал:

Вообще, Lua 5.2 тоже полезная вещь. Как минимум, пока в 5.3 не пофиксили баги при передаче таблиц компонентам.

по подробнее про этот баг, и вообще, в каком случаи таблицы нужно передавать компанентам?

18 часов назад, VBerezin сказал:

Дело в том, что данный форк не поддерживает Lua 5.2, исключительно версию 5.3, так как используются некоторые функции, которые не поддерживаются в версии 5.2. Чтобы запустить систему, достаточно сменить архитектуру на Lua 5.3.

добавь авто переключения архитектуры на lua 5.3(computer.setArchitecture("Lua 5.3")) главное чтобы стартовый сис файл компилировался на lua 5.2 иначе на сработает

18 часов назад, VBerezin сказал:

но и как полноценная терминальная система

а чем гуишная ос не полноценная, интересно было бы узнать

принципе, форк имеет место быть, надеюсь это выльеться во что-то интересное

В 05.08.2022 в 14:50, eu_tomat сказал:

Unix-like, конечно радует, но производительность в простых циклах очень огорчает.

которую я не тестил, потому что пишет мол шел, а потом пишет too long without yielding(не blue скрин)

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

о сейчас удалось попасть в shell, скорее всего это связано с пере заходом в игру, шас потестю

решил сменить моник на третий, и оно опять не хочет заходить в shell....

21 час назад, fantomas сказал:

Наверное уже все участники этого форума знают, что в opencomputers невозможено написать операционную систему с настоящей параллелизацией - достаточччно написать и запустить программу

local x = 0
while true do
  x = x + 1
end

и вся система зависнет, а затем компьютер перезагрузится с ошибкой "too long without yielding".

 

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

 

Достигается это при помощи вот этого кода, перед запуском любой програмы или вызовом функции load обрабатывающего запускаемый код посредством добавки coroutine yield между всякими двумя действиями.

 

Страницу операционной системы можно найти вот тут, а её ядро тут.

 

Успешного ознакомления!

 

идея отличная.

наконец-то что-то новенькое в open computers подъехало, да еще и unix-like круто, мне нравиться

но... какой пароль от root? я хочу потыкать ос подобрал, пароль от root: root

после входа в root ос приветствует, а потом too long without yielding....

31 минуту назад, eu_tomat сказал:

Это я понял. Только я не вижу тут универсального применения в отличие от утилиты flash. Пока я вижу лишь специальные случаи, в которых применение универсальной утилиты не даёт никаких преимуществ. Твоя утилита, конечно, имеет право на существование, но, скорее, как экзотика для гурманов, а не замена стандартной утилите.

ну да, софт не универсальный

31 минуту назад, eu_tomat сказал:

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

я думаю, что смогу сам написать арефмо кодер, и в скором времени этим займусь

32 минуты назад, eu_tomat сказал:

Другу потребуется выполнить следующие действия: скачать твою утилиту прошивки, скачать файл прошивки, скопировать строку запуска утилиты. А если всё это делать без твоей утилиты, то потребуется: скачать файл прошивки, скачать файл параметров (если требуется), скопировать строку, заполняющую код и данные EEPROM. В принципе, все эти три действия можно объединить в одну строку. Но в любом случае второй подход создаёт меньший трафик в сети и увеличивает надёжность за счёт исключения лишнего звена.

ладно, признаю, пример с нешарюшим другом плохой

33 минуты назад, eu_tomat сказал:

Да, существование ПО, параметры которого заданы извне, вполне возможно. Но в таких случаях к самому ПО прилагается и дополнительная утилита, обрабатывающая все необходимые проверки и умолчания. Также эту задачу зачастую перекладывают на документацию, текстовый редактор и голову системного администратора, такой подход тоже может быть удобным. Но применительно к обсуждаемой утилите он как раз неудобен из-за объединения в одном файле блока параметров с блоком кода, что усугубляется двоичным представлением сжатого кода. И это снова возвращает нас к специализированной утилите, написанной под конкретную задачу.

ну... проблема таких утилит в том, что они идут под api конкретной ос, а вдруг у меню другая ос?

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

1 час назад, eu_tomat сказал:

Ты же понимаешь, что данные на то и данные, что зависят от конкретных условий и могут меняться? А если эти данные могут меняться в процессе работы, то что мешает в процессе же работы их и сформировать?

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

1 час назад, eu_tomat сказал:

И эти данные никогда не меняются иначе как со сменой прошивки?

могут меняться

могут нет

могут меняться, но не все

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

1 час назад, eu_tomat сказал:

Вот тут соглашусь, я и сам таким баловался. Правда, в том случае в первую очередь использовалось сжатие кода, т.к именно оно обеспечивало максимальную экономию памяти, поэтому чтение из области данных EEPROM возлагалось на распаковщик, а запись в EEPROM — на упаковщик. Заметной прибавки это решение не давало, порядка 5%, но поиграться с дополнительной памятью было увлекательно.

5% уже могут за решать, но основной замысел, все-же будет задать дынные по умолчанию, если утилита flash шьет только сам скрипт, то утилита eeprom целый образ

8 минут назад, eu_tomat сказал:

Данные EEPROM, конечно, полезны. Но зачем хранить их вместе с прошивкой, если они содержат уникальные, практически не повторяющиеся адреса?

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

ты же понимаешь что данные в eeprom-data могут быть любые? если бы не столь маленький лимит eeprom то да, можно в код захардкодить коррекцию неправильных данных, но а в друг мне нужно часть кода поместить прямо в eeprom-data дабы сэкономить место?

там могут быть не только адреса, но и настройки биос, уже приводил пример, но приведу еще раз, там может быть таблица "{}" или даже уже забитая данными "{password = '222', oemUnlock = false, oemUnlockAllow = true}" и в код это может банально не влезть

цель дынной утилиты, создать максимально точный слепок eeprom для последующей передачи, или хранения

8 минут назад, eu_tomat сказал:

Что можно сделать с утилитой из этой темы? В первую очередь я рекомендую обеспечить совместимость формата со стандартной утилитой. Это поднимет шанс того, что её начнёт использовать кто-то кроме автора. Может быть, кому-то и вправду потребуется хранить всё это в одном файле с прошивкой. Интересно будет узнать об этих случаях и потом сравнить удобство стандартной и модифицированной утилиты.

ну... могу разве что pull-request кинуть, но вряд ли его кто-то примит

6 минут назад, eu_tomat сказал:

Ты же совсем недавно пропагандировал следование стандартам. А стандартная прошивка Lua BIOS успешно справляется с некорректными данными в EEPROM. И не просто справляется, а сама корректирует неверные данные. То есть, проблемы нет. Или от следования стандартам ты уже отказался?

я пропагандировал, следования внешним стандартам общения между биос и ос, но я не против их дополнения, так например при использовании microbios, computer.shutdown("bios") перезагрузит тебя прямо в меню bios а computer.shutdown("fast") перезагрузит минуя вход в меню биос(тебе не предложит его открыть), однако если у ОС своя прошивка eeprom и не предполагается установка нечего костюмного то в особых случаях, как например зашишенная ос, стандартами можно пренебречь

9 часов назад, Fingercomp сказал:

Напомню, что есть /dev/eeprom и /dev/eeprom-data. С тех пор, как эти файлы реализовали в OpenOS, надобность в утилите flash отпала совершенно.

# cat bios.lua > /dev/eeprom
# echo > /dev/eeprom-data
# cat /dev/eeprom > bios.lua

 

ну... принципе да, но у меня пару раз бинарные данные при чтении из /dev/eeprom бились!

7 часов назад, eu_tomat сказал:

Но раз тема не шуточная, можно обсудить её по существу:

Мне не приходилось сталкиваться с подобным. Приведи примеры программ, работающих некорректно из-за сохранения старых данных в EEPROM. И каким программам требуются данные по умолчанию?

чужим софтом не пользуюсь, но с подобной ситуацией сталкивался, прошивая один из моих биосов после lua bios он крашился, так как в eeprom-data был адрес загрузочного диска, а биос ожидал там увидеть адрес монитора, по сути любая программа может работать некорректно если не стереть eeprom-data, да и гораздо удобнее поместить данные в файл, чем занимать драгоценное место в основном разделе eeprom, например если в eeprom-data ожидается сериализованая табличка, то в файл можно сразу поместить пустую табличку "{}"

В 28.07.2022 в 22:01, eu_tomat сказал:

Ссылка на программу отсутствует, но это не страшно. Ведь полное копирование EEPROM вместе с меткой, данными и флагом ReadOnly можно выполнить на верстаке.

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

PS. и мог нормально в лс сообщить о отсутствии ссылки? что за хейт? да можно через верстак но это не значит, что программа не нужна