ECS

В 06.12.2024 в 00:34, ProgramCrafter сказал:

Двойным кликом по ярлыку на рабочем столе программы совершенно не хотят запускаться.

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

В 06.12.2024 в 00:34, ProgramCrafter сказал:

Интерпретатор Lua: не прокручивается на последние 1-2 строки, где, собственно, последняя команда и её вывод)

История вывода ограничена 100 строками. Рискну предположить, что ты заюзал for i = 1, 100 print(i), из-за чего оригинальная команда попросту стёрлась, превысив лимит?

В 06.12.2024 в 00:34, ProgramCrafter сказал:

Picture Editor не позволяет поменять размер холста на заданный, а при попытке расширить размер холста вправо-вниз вовсе вылетел.

Размер холста до желаемого можно поменять через инструмент Select, выделив нужную зону и нажав кнопку "Crop", т.к. мне показалось это более удобным, нежели ввод цифр. А вылет при расширении пофиксил, спасибо <3

В 06.12.2024 в 00:34, ProgramCrafter сказал:

(возможно, забыл) неясно, как открыть несколько вкладок в MineCode IDE.

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

В 06.12.2024 в 00:34, ProgramCrafter сказал:

хотелось бы: функцию input() для терминала

Я и терминал-то подумываю снести к чертям, т.к. добавлял его из-за бесконечного воя на гитхабе, мол, "а-а-а, верните мой print(), я копаюсь в грязи и не хочу тыркать енти ваши кнопочки". Это UI-only ось, заточенная под приложухи, кнопочки, слайдеры и инпуты. Если нужен терминал - думаю, стоит воспользоваться терминальной осью. Плюс не вижу разумных причин, по которым tonumber(io.readLine()) удобнее tonumber(input.value). Дело привычки скорее

В 06.12.2024 в 00:34, ProgramCrafter сказал:

хотелось бы: в контекстном меню для программы опцию "запустить"

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

По коду ничего не понял, извини. Сам обработчик удаляется сразу же после вызова removeHandler без скрытой логики. Плюс, судя по ошибке, переменная server на каком-то этапе была удалена

Ошибка PKIX происходит  из-за устаревших сертификатов в хранилище Java. Либо обновляй её, либо сертификаты. Вручную или автоматически - это уже не суть важно. А пастбин жалуется как раз из-за неё

@PetyaBorisov обнови Java

@TurboPointbus300 боюсь, она умерла.............. 💀⚰️⚱️

Прости, мы сочли священным долгом отпентестить сей шедевр. Уязвимостей не обнаружено, комиссия ставит 10/10 на кончиках пальцев

В 12.02.2024 в 04:07, Zigo сказал:

похоже что пастбин забанил Ваш установщик библиотек

Да, пару лет назад снесли аккаунт. Исходников инсталлера нет, библиотека забыта, саппорта не будет, репозиторий в архиве, писать заново лень. Так что придётся самому

Коллекция штатных приложений пополнилась аудиофильской репликой Pioneer CDJ-2000 nexus с функционалом, близким к оригиналу - насколько позволяет мод, разумеется:

• Поддержка нескольких кассет, играющих параллельно
• Cue и Loop-метки с банком памяти и горячими вызовами
• Навигация по треку через джог, needle search bar или кнопки fov/rew
• Регулировка темпа и громкости фейдерами и кнобами
• Подстройка чувствительности элементов управления
• Визуализация длительности трека, текущей позиции или остатка
• Запись композиций на кассету с HDD и URL 
• Скевоморфный UI с подсветкой и имитацией питания от сети

В обозримом будущем хотелось бы заиметь анализ трека с построением пиков, определением "бочек" и квантованием меток, однако это потребует специфичных скиллов, нудного гугления всяких PCM, IFT, DFPWM и т.п., поэтому пока что и так сойдёт)0

@ZKoshak увы, нет, т.к. на Wayback Machine оно не трекнулось, а исходников в истории коммитов на гитхабе от 02.05.18 тоже не нашлось. Видимо, я их вообще не заливал никуда, кроме пастбина

Ну, тогда смерть. Можешь попробовать "ПКМ - создать приложение", система сгенерит шаблонный .app,  где как раз реализована поддержка меню. Если оно там будет работать - то ищи ошибку у себя, а если нет - надо думать дальше. Без фулл сырцов трудно что-то сказать

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

Запускалось через pcall потому-что иначе system fatal error: nil.

В нормальных условиях меню может не вернуться в двух случаях:

1) Когда окно форсированно игнорирует добавление в док и меню, т.е. system.addWindow(window, [addToDockAndMenu = false]). Обычно этот параметр используется для утилитарных окон, например, при ПКМ на файле -> Properties. Но, судя по всему, это не твой случай

2) Когда ты добавляешь окно в воркспейс системы не из Name.app/Main.lua, а из внешнего скрипта, загруженного через loadfile/dofile/readfile - это захардкожено вот тут. Система пытается получить путь к директории приложения, чтобы адекватно визуализировать иконку и имя в доке и в меню, но не может т.к. внешние файлы не считаются приложениями. Поэтому добавление в меню и док скипается

Собственно, выход один: добавлять окно в основном скрипте приложения. Ещё было бы разумно доработать анализ пути исполняемого скрипта, чтобы искать последнее вхождение .app/ и не создавать анальных ограничений. Ну или хотя бы кидать ошибку, мол, "ай-ай-ай, так нельзя". Но лень хд

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

Для тех, кому лень читать длинный текст:

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

Мы получаем 2 числа, а нужно одно

Ну дык склей эти 2 байта через

byte1 << 8 | byte2

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

Как из них получить 1 цифру, ту-же 1007 которую мы и вкладывали?

Ту же самую - никак, библиотека unicode не имеет функции codepoint. Поэтому приходится довольствоваться string.char/string.byte и комбинировать их с unicode.char

Из символа в байты:

local char = unicode.char(128)
local bytes = {char:byte(1, #char)}

print(table.unpack(bytes))
> 194 128

Из байтов в символ:

local bytes = {194, 128}
local char = string.char(table.unpack(bytes))

print(char)
> ┬А -- unicode.char(128)

25 минут назад, WheatComp сказал:

следующий код дает ошибку:

Чтобы что-то закрыть, нужно сперва это что-то открыть. Компонентный вызов open() возвращает дескриптор файла, а APIшный - буферизированный поток, и работа с ними отличается:

local filesystemAPI = require("filesystem")
local filesystemComponent = require("component").filesystem

-- API
local stream = filesystemAPI.open("/test.lua", "w")
stream:write("Hello world")
stream:close()

-- Компонент
local handle = filesystemComponent.open("/test.lua", "w")
filesystemComponent.write(handle, "Hello world")
filesystemComponent.close(handle)

И вообще не по каждой же строчке кода пинговать форумчан, давай сам думай. Наверняка там ошибка наподобие attempt to call a nil value (field 'close'), означающая, что в filesystem API не существует метода close()

13 часа назад, WheatComp сказал:

Пытался по этой инструкции делать, оказалось, w нужно брать в кавычки:

Рекомендую следовать инструкциям не из комментов, а из официальной вики или готового софта - так будет существенно меньше проблем

8 часов назад, WheatComp сказал:

spaceUsed() все время показывает 512, хотя добавил в директорию диска 2 файла по 1 Мб. Как бы обновить показания?

При работе с дисками напрямую из директории игрового сейва пересчёт spaceUsed не производится. Для быстрого пересчёта необходимо вызвать filesystem.close(), т.к. это единственный метод, который его инициирует напрямую. Вероятно, пересчёт также должен осуществиться, если вытащить и вставить диск в ПК, но это не точная инфа, надо курить поведение мода и принципы реинициализации компонентов

Если интересны подробности, то причина такого поведения в дороговизне вычисления размера директории, к которой привязан диск - оно выполняется рекурсивно, суммируя размеры всех файлов во всех дочерних директориях. Мод частично решает эту проблему, кешируя значение spaceUsed однократно при инициализации компонента. Затем при любой операции над файлом, когда его размер предсказуем, кешированное значение изменяется без потребности в пересчёте с нуля

Уточню, что при "естественном" обращении к диску эта проблема вообще никогда не возникнет, т.к. мод выполняет всю работу по пересчёту самостоятельно

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

Если это разные объекты, то почему они называются одинаково

Я одного не пойму: почему тебя так зацепило это явление, неужели оно создаёт настолько серьёзные проблемы? Ведь и в повседневной жизни, и в разговорной речи встречаются омонимы - ключ/лук/мат/лист/коса/каток и прочие. К ним у тебя такое же радикальное отношение или, может быть, это всё же дело привычки?

Если взять пример из области кодинга, то в большинстве языков программирования имеется концепция пространств имён, разграничивающих доступ к классам с одинаковыми названиями: в том же .NET имеются System.Windows.Media.Color и System.Drawing.Color. Какой using укажешь - такой класс и будет использован. Схожая путаница возникает между java.nio.file и java.io.file. Эт норма))0

42 минуты назад, WheatComp сказал:

По-моему, это единственный компонент, который можно включать в программу и через точку и через require. А если назвать одинаково, есть высокие шансы, что юзеры запутаются. Не совсем юзерфрендли решение.

Аналогичная история с компонентами internet/computer/robot и одноимёнными библиотеками. Это скорее систематика и фича, нежели однократная проблема нейминга

Вообще с одной стороны ты прав, и путаница имеет место быть. А с другой - наверняка нашлись бы недовольные альтернативной реализацией, дескать, "А чо у вас компонент зовётся filesystem, а API disksystem? Дискеты - ето уже диски? Сложна!1"

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

Разве плохой код - плюс? К тому же, в ОС есть аппаратные ограничения. А в СС они достаточные.

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

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

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

Потому что это челлендж, а жизнь без челленджа скучна и пресна, как еда из столовки в сравнении с рестораном. Плохо, когда челленджа нет, как в CC. Плохо, когда он чрезмерен, как в GregTech. И хорошо, когда он сбалансирован - как в OC

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

А зачем? Был где-то пост почему НЕ стоит писать свою ось.

Затем, что наличие возможности, которая тебе не пригодится, всегда лучше её отсутствия, при котором она не пригодится никому. На форуме были также посты от авторов альтернативных ОСей, которые пишут их, несмотря на предостережения. Так к которому из авторов стоит прислушаться рабу системы? Я считаю, что одновременно ко всем, и ни к кому. Пост - это не более чем компиляция мыслей одного человека. Можно воспринимать их как рекомендацию, можно как личное кредо - но не как незыблемую догму для всего человечества. Один усатый художник тоже много чего писал)0

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

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

Ну, если сам BenniShifer919 не видел, то фичи действительно юзлесс, можно удалять из мода - сейчас кину PR авторам. А способность думать логически и пространственно зависит в том числе и от объема доступного инструментария. Чем он шире, чем гибче - тем лучше, т.к. перспективы и масштабы мышления расширяются. В случае с CC из-за облегчённого геймплея и недостатка фич они наоборот сужаются, а мыслительные процессы текут более вяло, позволяя ошибаться и писать плохой код чаще

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

И не замечал проблем с производительностью, в отличии от ОС

Потому что не играл на серверах, где рандомный гений крафтит стак компов из мусора, запускает while true и убивает хост за пару минут. OC искусственно ограничен для лучшей иммерсивности, и более-менее защищён от абьюзеров, он учит писать качественный код, не поедающий доступные ресурсы впустую, а CC - нет

К примеру, несколько лет назад мне пришлось изрядно попотеть и изучить много нового, чтобы накодить на OC рейкастер с приемлемой производительностью, т.к. при бездумном кодинге движок выдавал лишь 1-2 FPS. Я очень радовался, что осилил, что сумел, что превозмог трудности. Это сродни получению достойной награды за действительно тяжелый труд. Как сказал бы Сэнку: "Это так волнительно!"

12 часа назад, BenniShifer919 сказал:

У него нету сильных недостатков перед OC

А знаешь, чего у него ещё нет?

• Нет аппаратных ограничений, что позволяет забить на оптимизацию софта, уничтожает челлендж, а новичков приучает бездумно писать плохой код. Ты думаешь, почему любой AAA-проект в 23 году имеет в минимальных требованиях RTX 2080? Всё потому что джуны учились кодить на CC!
• Нет сбалансированных рецептов крафтов, ПК в буквальном смысле создаётся из мусора. Это создаёт ложные представления о реальности, обучает требовать максимум, прикладывая минимум усилий. Сегодня ты кодишь на CC, завтра требуешь ЗП в 300к/наносек, а послезавтра спиваешься от разочарования!
• Нет возможности снести захардкоженную CraftOS и написать собственную взамен. Это пресекает на корню свободу творчества, уничтожает здоровую конкуренцию и приучает с ранних лет считаться с требованиями монополиста. Разве такого будущего мы желаем нашим детям?
• Нет тонны фич типа 3D-принтера, геосканера, голопроектора, карты данных, связанной карты, датчика движения, контроллера баков, транспозера, поводка, дронов. Человек не может развиваться, сознательно отказываясь от этих благ. Это путь к деградации и самобичеванию, к искусственным ограничениям и невежеству!
• Нет даже War Thunder! А знаешь, где есть War Thunder? В OC, вот пруф!

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

@ECS Почему-то начала выскакивать ошибка, как только открываю порт, на который приходит сообщение по сети

Судя по ошибке, в дисководе до сих пор установлена дискета Network, которая проворачивает в фоне какую-то чёрную магию, регистрируя глобальные обработчики событий. Решение: вынуть дискету и ребутнуть ПК

47 минут назад, WheatComp сказал:

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

Боюсь, лут-дискеты - это скорее примеры того, что можно сделать средствами мода, а не "убер-проги" на все случаи жизни. Реально полезны и функциональны из них лишь OpenOS, OPPM и IRC, остальные декоративно-рудиментарны. Предположу, что их не удаляют ради элемента фана - всегда забавно найти какую-нибудь рандомную софтину в адском данже. А, может быть, ради совместимости со старыми сейвами или просто потому что лень

47 минут назад, WheatComp сказал:

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

Пишем собственные под конкретные задачи. Работа с сетью в опенкомпах довольно удобна, поэтому новый софт создаётся быстро, если, конечно, речь не идёт о шифровании или каких-то специфических форматах передачи данных с компрессией. Ну, а когда кодовая база становится довольно объёмной - оформляем её в виде библиотек и выкладываем, чтобы их засрали)0

1 минуту назад, WheatComp сказал:

Как же тогда тут удалось обойтись без .amount?:

Функция pairs возвращает итератор, который проходит по всем элементам таблицы tankTable, позволяя обработать их ключ и значение. Amount является ключом, причём строковым

Иными словами, чтобы "обойтись" без .amount, нужно перебрать все элементы таблицы, что лишено практического смысла из соображений производительности

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

amount - это не цифра

Согласен, это буквы. Тем не менее, чтобы выразить доступ к "amount" в одном вызове print'а, необходимо использовать именно такую языковую конструкцию:

Вызов по численному индексу невозможен, amount в этом случае не имеет численной замены для доступа к значению. Поэтому только буковки