eu_tomat

Кабы геосканер мог события генерировать, тогда бы и был в нем смысл, а так он помогает лишь тратить энергию. robot.detect() значительно дешевле обходится.

Тоже привык, и ничего удобнее не встречал. Но на прошлой неделе меня вдруг начала раздражать повторяющаяся последовательность: сохранить изменения в файл, переключиться в консоль, запустить код, посмотреть на результат, переключиться обратно в редактор. Никогда не понимал подобных заявлений, а vim открывал лишь для того, чтобы ужаснуться, закрыть и забыть. Но на прошлой неделе я психанул, и, потратив два дня, нагуглил ответы на каждый свой вопрос, прошел vimtutur ru, составил простенький .vimrc для начала, и повесил хоткей на выполнение последовательности из двух команд: сохранить изменения и запустить файл на выполнение. Так по рецепту @Fingercomp я и обрел свое счастье в vim'е.

Я почему-то решил, что это Zn предлагается в качестве общественной сети на сервере, как было с OpenNet.

Да тут на самом деле каждый ответ порождает новый вопрос. Ну, отбросим мы сообщения с nil в хеше. Так можно тупо заспамить сеть, крашнув узлы либо переполнением памяти, либо выпадением в TLWY при переборе хешей. Сделать валидацию хешей? Но спамить можно и валидными хешами. Добавить кулдаун для каждого соседа или счетчик хешей? Так и сам сосед может оказаться честным репитером и вообще, узлом собственной сети. Исходного адресата тоже не найти, т. к. его адрес легко подделывается. Можно изначально строить собственную сеть ретрансляторов как закрытую, где все узлы знают адреса друг друга и доверяют им, но не доверяют любым другим. В случае высокой активности чужие узлы отправляются во временный бан независимо от того, принадлежат ли они вредителю или честно ретранслируют пакеты. Пусть владелец той сети сам заботиться о том, какие узлы заслуживают доверия, а какие нет. Для дополнительной защиты можно даже использовать шифрование. Но даже эти шаги не решают другой проблемы. Есть, к примеру, робот. И адрес его модема валиден, и даже ключи шифрования у него есть. Но робота угнали, и теперь вся сеть скомпрометирована. И что делать тогда? Выдать каждому устройству сертификаты? Но тогда на каждом устройстве придется хранить открытые ключи всех устройств сети и сверяться с ними при каждом удобном случае. Ретрансляторы на EEPROM могут выпасть из этой схемы. И возникает главный вопрос: выдержит ли сервер всю эту криптографию?

А если злодей отправит nil вместо хеша, это не убьет ближайшие узлы на строке hashes[hash] = computer.uptime()?

1) Разве всеядность LZ77 является недостатком? Вот, урезание диапазона входных данных это скорее минус, нежели плюс. Но если настаивать на нем как на «плюсе», то с его помощью слегка модифицированный LZ77 дополнительно отожмет еще две-три сотни символов. Но сейчас даже без этого сомнительного трюка LZ77 выглядит более эффективным. 2) Не знаю, портит ли crunch код, но его реализация LZ77 точно не самая эффективная. Особенно учитывая, что в самораспаковывающемся коде можно сколь угодно далеко уйти от стандартного алгоритма. Главное, код восстановить. Так вот, пример crunch демонстрирует, что потенциал LZ77 еще не исчерпан. По крайней мере, реально впихнуть 8615 байт уже минизированного Lua-кода в 3300 вместе с шустрым распаковщиком. Вот эти циферки в сравнении с твоими я и предлагаю обсудить. 3) Недословарь, ограниченный 127 словами, будет сильно тебя сдерживать. Отказавшись от фиксированных размеров как словарей, так и ссылок, мне удалось заметно увеличить степень сжатия. Разумеется, моя версия LZ77 тоже имеет ограничения – упаковщик слишком медлителен на больших файлах, но главной задачей я поставил подготовку кода для EEPROM, где хороши все средства ради входа в заветные 4096 байт. 4) Нет смысла говорить об эффективности LZ, не имея в виду конкретную его разновидность и реализацию. Одних только LZ77 я встретил три разных описания, и то, я был не сильно настойчивым в поиске. Предпочтет ли LZ более или менее эффективное слово, сильно зависит от примененных эвристик и зачастую даже не требует изменений в формате файла. Поэтому сейчас я бы предпочел рассуждать не об абстрактных преимуществах алгоритма, а его числовых характеристиках. Мне интересно, улучшилась ли твоя оценка сжатия для тех файлов, что я скинул, и насколько. На раскрытии деталей можешь пока не заморачиваться, достаточно указать выходной размер вместе с распаковщиком.

Молиться недостаточно. Надо еще и поститься. И слушать радио «Радонеж». Кстати, OpenNet при таком подходе не появился бы на свет. Смельчаки просто взяли, да и написали кластер для своих нужд.

Выполнил я кое-какие расчеты на основе LZ77. Есть мнение, что файл из примера (8615 байт) после сжатия не будет превышать 3300 байт вместе с распаковщиком. crunch, к примеру, жмет этот файл лишь до 4581 байт. Вопрос: Насколько востребован такой упаковщик? И стоит ли его доводить до работоспособного состояния? Сейчас я могу примерно оценить итоговый объем сжатого файла. Можно довести и до выдачи сжатого кода. Далее есть несколько участков кода, явно требующих оптимизации, т. к. сейчас всё писалось исключительно для проверки идеи. В OpenComputers не запускал, и как будет тормозить упаковщик, даже не представляю. Распаковщик вряд ли будет тормозить, т. к. поток распаковывается в один проход, и его алгоритм немногим сложнее того, что встроен в crunch. Юникод, само-собой, поддерживается.

UX-дизайн все-таки зверский. И пульты управления АЭС образца СССР – не лучший пример для подражания. Сложность хороша там, где она неизбежна.

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

@@Barsik121 1) Правильно ли я понимаю, что шина из Project Red – это связка цветных проводов? Если так, то тебе может помочь тема о передаче данных по редстоуну. Правда, надо еще проверить, как передаются разные уровни сигнала по цветным проводам и связкам. 2) Для передачи данных между OC-CC удобнее использовать обычную сетевую карту в компьютере OC, а для компьютера CC в качестве периферии поставить коммутатор из OC. Это позволит пересылать сообщения между OC-CC привычным способом.

Пора уже вводить орденские планки.

А чем фермы Forestry лучше ферм на роботах?

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

Во-первых, Lua позволяет оперировать целыми числами заметно длиннее четырех байт. Если я верно помню, можно свободно рассчитывать на 53 бита. Во-вторых, автор вопроса не уточняет свойства хранимых в массиве чисел: А если числа в массиве сильно ограничены, помещаясь в один байт? А если числа в массиве часто повторяются? Тогда дисковая память будет расходоваться неэффективно. Можно сжимать, но тогда не так эффективно будет расходоваться время процессора. Поэтому придется ответить на еще один вопрос: какое соотношение между занимаемым объемом и выполненными вычислениями является оптимальным?

Вот, и врачу все твердили: мол, очень долго у твоих больных идет процесс выздоровления, можно бы уже и в морг их отправить. А тот упорным оказался – вылечил-таки больных. Не всех, правда.

Это выше моих сил. В любом случае, у тебя где-то вставлен tank_controller, которого быть не должно.

Хм... Компонент называется tank_controller, совсем не похоже на tankvalvetile. Ты апргейд контроллера цистерн что ли закинул в адаптер? Вынимай его, снова включай программу, и все заработает.

А что выдает components?

Значит, адаптеры не подцепились к танкам.

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

А где ссылка на пакет в репозитории? А вот же она!

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

@@Wanderer13, небольшое уточнение. Хотя pcall и является мощным средством для продолжения выполнения программы, невзирая на ошибки, не стоит забывать и об уже прозвучавшей аналогии: Игнорирование одних ошибок может спровоцировать ошибки впоследствии, т.к. рано или поздно тормоз все-таки потребуется. Лучшим средством для борьбы с ошибками является поиск и устранение вызвавших их причин. В случаях, когда причину ошибки невозможно контролировать изнутри программы, имеет смысл использовать pcall. Очень редко возникают и другие случаи, когда использование pcall объективно лучше других методов обойти ошибку, но в целом от использования pcall лучше отказаться. Поэтому не стоит ставить вопрос таким образом: Гораздо полезнее потратить силы на то, чтобы понять причину ошибки в каждом конкретном случае. При отсутствующем модеме – не задействовать его возможности, если они являются не обязательными. При отсутствующем файла на диске – создать его. При не полученном от сервера сообщении – дождаться его или повторить запрос. Нет универсального средства обхода ошибок, даже если pcall кажется таковым.

@@Fingercomp, мне одно не понятно: для чего задействованы все эти трюки с метаметодами? В чем преимущество такого кода перед более простым? Можно же сначала тупо (через load/pcall) всосать файл в таблицу cfgUsr, а потом аккуратно перенести нужное в таблицу cfgWrk, изначально хранящую дефолтные значения. Заодно можно проверить и совпадение типа, и лишние поля в файле конфигурации. function cfgUpd( cfgWrk, cfgUsr, prefix ) local prefix = prefix or "" local type_v -- перебор значений таблицы cfgWrk, -- перенос (с удалением) соответсвующих значений из cfgUsr for k,v in pairs(cfgWrk)do if cfgUsr[k] then type_v = type(v) if type(cfgUsr[k]) ~= type_v then error("Ошибка в файле конфигурации: type("..prefix.."."..k..")~="..type_v,0) end if type_v~="table" then cfgWrk[k] = cfgUsr[k] else cfgUpd( cfgWrk[k], cfgUsr[k], prefix.."."..k ) end cfgUsr[k]=nil end end -- перебор таблицы cfgUsr, все это ошибочные поля for k,v in pairs(cfgUsr)do error("Ошибка в файле конфигурации: недопустимое поле '"..prefix.."."..k.."'",0) end end Upd: Сегодня взглянул на свой код еще раз, он неправильно обрабатывает лишние поля во вложенных таблицах. Позже перепишу.