eu_tomat

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

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

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

2 минуты назад, ZO125 сказал:

Вообще если исключить факт существования внешних средств коммуникации между игроками

Я уже понял, что основной смысл использования таких чатиков заключается в отыгрывании определённых ролей. Для меня этот вопрос исчерпан. Спасибо за объяснение.

14 минуты назад, hohserg сказал:

Можно юзать очки OpenGlasses

Недостаток очков в том, что они не защищают голову, а с шлемами они несовместимы. А так да, в своём доме можно и в очках бегать.

3 минуты назад, ECS сказал:

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

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

23 минуты назад, Del сказал:

не удобно для каждого друга делать свою прогу

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

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

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

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

А так, да: урок мутноватый, его поймут только подготовленные умы. Я стараюсь писать ясно и просто, но не продолжил серию. Зато взялся @Doob. Если он не захочет переписать этот урок, эту эстафету может принять кто-то другой, чтобы описать методику понятным языком. Сам я надеюсь вернуться к этой теме, но не в ближайшее время.

44 минуты назад, Grobovshik5121 сказал:

while true do

  F = redstone.getInput("front")

    if (F == true) then

      redpulse("back", 1, 6) 

    end

  sleep(1)

end

 

Ошибка появляется при подаче сигнала на front и выглядит таким образом:

, temp:4: attempt to call nil

Ошибка сообщает о попытке вызвать неопределённую функцию.

Как определена функция redpulse?

Мысли об измерителях TPS:

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

Комментарии к этой реализации счётчика и формулировке вопроса:

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

4 часа назад, Belzebub сказал:

Подозреваю что я криво измеряю tps

Измерение TPS, конечно, кривоватое, но какое отношение оно имеет к измерению расхода энергии? Ошибка, скорее всего, содержится в формулах расчёта расхода. Для более точного ответа недостаточно имеющейся информации. Или...

4 часа назад, Belzebub сказал:

Видик на котором видны куски кода, результаты измерения на экране компа и ручные замеры

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

Оказалось, что web-версия GitHub также имеет ограничение частоты запросов. Правда, OpenComputers настолько сильно ограничивает скорость приёма данных, что ограничения самого GitHub перестают играть реальную роль.

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

Цитата

Whoa there!

You have triggered an abuse detection mechanism.

Please wait a few minutes before you try again;
in some cases this may take up to an hour.

Если коротко: GitHub обнаружил злоупотребление и предлагает мне замедлиться.

Фраза же "Whoa there!" вообще пытается намекнуть на мою неадекватность.

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

Однако насчёт локальной переменной ты тут лишка хватил, т.к. любой итератор по типу pairs/ipairs является не более чем функцией-обёрткой, хранящей этот самый счётчик в виде скрытой локальной переменной.

Я говорил именно про объявление локальной переменной внутри цикла, это чисто косметический эффект. Если мы хотим избавиться от индексирования таблицы, переменная создаётся в любом случае – явным образом или нет.

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

Это потом уже пошла дискуссия на тему "как быстрее"

Да, я понял. Мне показался слишком категоричным призыв отказаться от использования итератора ipairs. Но сейчас твоя позиция мне полностью понятна.

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

Ой, что же это? Медленнее в 2.7 раза?

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

При этом использование ipairs позволяет писать более читаемый код, позволяя отказаться как от использования индексов, так и от объявления локальной переменной внутри цикла. Ценой такого решения будет снижение быстродействия, но оно не всегда критично, а читаемость кода может оказаться важнее.

Как найти оптимум, это отдельный и сложный вопрос. Пожалуй, хорошей привычкой будет писать обычные циклы for i=1,#tbl, и если код кажется трудно читаемым, хорошенько подумав о последствиях, применять for i,v in ipairs(tbl).

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

изначальный метод сортировки невалиден для table.sort, т.к. не учитывал все возможные варианты

Да, дело именно в этом. Вместо else нужно было писать elseif not ply1.online and not ply2.online then, а также поменять знак при сравнении offline_time.

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

Но первый делает это за семь минут, пятьдесят три секунды, а второй за ноль минут, двенадцать секунд. Результат на лицо. Вывод: первый вариант мало применим. Можно либо использовать второй вариант, либо выносить получение списка файлов за пределы майнкрафта.

А если отказаться от скачивания web-версии файла и разбирать сразу ссылку, как говорилось здесь:

В 02.03.2021 в 07:46, eu_tomat сказал:

Нам же не обязательно скачивать и разбирать web-страницу файла. Достаточно разобрать ссылку! И если обнаружена ссылка на файл, то можно сразу  скачивать её raw-версию

То время сократится до 90-100 секунд.

А если web-версию использовать лишь для подстраховки при отказе обслуживания API, то время сократится ещё сильнее.

@hohserg Мы выше разбирали вариант с API, но есть трудность:

В 25.02.2021 в 18:09, eu_tomat сказал:

https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting

Простым языком: для анонимных пользователей доступно не более 60 запросов в час с одного IP-адреса.

 

Из-за этого решение на базе API может оказаться нестабильным. Особенно, учитывая, что на одном IP может работать несколько серверов, и на каждом сервере может играть больше одного игрока.

11 час назад, AlexCatze сказал:

Сейчас воюю с парсингом raw ссылки, но что-то мне кажется, что это бессмысленно.

Кстати, да. С утра мне это тоже показалось бессмысленным.

Нам же не обязательно скачивать и разбирать web-страницу файла. Достаточно разобрать ссылку! И если обнаружена ссылка на файл, то можно сразу  скачивать её raw-версию:

https://github.com/{AUTHOR}/{REPO}/tree/{BRANCH}/{PATH}
https://github.com/{AUTHOR}/{REPO}/blob/{BRANCH}/{PATH}/{NAME}
https://raw.githubusercontent.com/{AUTHOR}/{REPO}/{BRANCH}/{PATH}/{NAME}

Строки ссылок короткие, поэтому тут можно смело применять шаблоны, не опасаясь TLWY.

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

TLWY нету, но работает это краааайне медленно.

Сам разбор работает очень быстро, если использовать find без шаблонов. Медленно работает получение страницы, тратя один такт времени на каждый кусок. А кусков много, Web-версия гораздо объёмнее, нежели API. Очень странный подход у владельца гитхаба – ограничивать быстрый и компактный вариант, не ограничивая медленный.

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

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

С этим я согласен. Но инсталляция требуется один раз, на эксплуатации программы это никак не скажется. Зато программист может не тратить своё внимание на обновление установщика при каждом изменении. Но я не настаиваю на этом решении. Я могу лишь предлагать.

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

Сейчас воюю с парсингом raw ссылки, но что-то мне кажется, что это бессмысленно.

Почему же бессмысленно? Фраза id="raw-url" встречается на странице лишь один раз или не встречается вовсе.

6 часов назад, AlexCatze сказал:

Попробовал, веб в  версии отрабатывает, а в локальной всё тот же TLWY.

Тогда я не вижу другого варианта кроме использования find без шаблонов. Код распухнет строк на 10, но, как ни странно, он работает гораздо быстрее библиотечных функций:

local sHead, sTail = 'data-pjax="#repo-content-pjax-container" href="', '">'
local pTail, pHead = 1
while true do
  pHead = html:find( sHead, pTail, true )
  if not pHead then break end
  pTail = html:find( sTail, pHead+#sHead, true )
  if not pTail then break end
  print( html:sub(pHead+#sHead,pTail-1) )
  pTail = pTail+#sTail
end

На моём компьютере этот код можно выполнить примерно 1-1.5 тысячи раз до наступления TLWY, запас огромный.

@AlexCatze Предлагаю вместо этой конструкции:

html:gsub( 'data%-pjax="#repo%-content%-pjax%-container" href="(.-)">', function(s)os.sleep(0)print(s)end )

использовать такую:

for s in html:gmatch( 'data%-pjax="#repo%-content%-pjax%-container" href="(.-)">')do os.sleep(0)print(s)end

Работает раза в два быстрее.

Web-версия оцелота успешно отработала этот код.

23 минуты назад, AlexCatze сказал:

В веб версии оцелота то же самое.

У меня аналогичный опыт. Но это очень странно. Веб-версия оцелота отработала до истечения таймаута на два порядка больше итераций пустого цикла, чем в игре на моём компьютере. Зато при обработке gsub почему-то валится в TLWY. Может, Ocelot кривоват?

@AlexCatze Похоже,  на этом железе и на таком объёме данных gsub не успевает выполнить даже одну итерацию за отпущенный ему таймаут. Жаль. Придётся использовать более сложные способа разбора.

14 минуты назад, AlexCatze сказал:

Так?

...

Только что попробовал, эффект тот же.

Да, верно. А хоть что-нибудь успевает распарситься?

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

Попробовал на эмуляторе ocelot, получил TLWY. Видимо ответ слишком большой для gsub.

Проверил у себя на компьютере, gsub в моём примере выполнился за 2.5 сек. А стандартный таймаут для TLWY составляет 5 сек. Запас по времени маловат, поэтому решение неустойчивое, на слабом железе работать не будет.

Предлагаю в вызываемую функцию добавить os.sleep(0).

14 часа назад, AlexCatze сказал:

Тогда есть смысл использовать старый инсталятор.

Лучше тогда разбирать web-версию гитхаба. Решение, конечно, медленное, но зато не требует обновлять код установщика при изменениях файловой структуры. Можно даже комбинировать вызовы к API и Web в зависимости от исчерпания лимита.

@AlexCatze Я столкнулся с неприятным свойством API GitHub:

https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting

Цитата

For unauthenticated requests, the rate limit allows for up to 60 requests per hour. Unauthenticated requests are associated with the originating IP address, and not the user making requests.

Простым языком: для анонимных пользователей доступно не более 60 запросов в час с одного IP-адреса.

Из-за этого решение на базе API может оказаться нестабильным. Особенно, учитывая, что на одном IP может работать несколько серверов, и на каждом сервере может играть больше одного игрока.

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

Может ли хранилище Open Source кода быть проприетарным?

Пойдём от обратного: Что мешает хранилищу открытого кода быть проприетарным?