Вечером на shaos потестю. Если первое, то мне подходит

https://sprinternet.io/iii/u/e/lor.opennet/bot.habr.rss/-2:2

lor.opennet
xfSBW60zRzlgSwVk76AQ
LhwoSH409gDoNlImRkqj
bot.habr.rss
qXIZLzo3Qe9lx8MA8agu
AAGRBdSX5ijxRWvXecPm

ок

другие станции

http://hugeping.tk/u/e/retro.talks/idec.talks/-2:2

retro.talks
5B3Tra1DRJEcymDcA6Gi
XOjs0DTBN77YYkJT2drY
idec.talks
Jr1i7Uh3aExR45L4mILq
lQojMgQzCqNwlULJtw3g

думаю, это и есть стандарт.

2shaos - я с тебя буду грабить только последние 100 сообщений. и так благодаря /x/h трафик между станциями упал с 12 мб до 2 мб, а так вообще урежется :)

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех запросит. В стандарте есть пример, я его прислал. Но ты похоже его даже не читал.

https://club.hugeping.ru/u/e/idec.talks/std.hugeping/-1:1

Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)

2shaos - фетчеры обновил

у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш

а какие бывают текстовые игры, применимые в эхах?

помню в ru.golovolomka в данетки играли. в vga.planets, вроде, только нетмейлом играли, как там эхи использовались, не вспомню. кто ещё что может вспомнить?

> 2Shaos, хочу с тебя дёргать только последних 100 хедеров, как у тебя нода устроена?

-100:100

У меня стандартный IDEC

Был :)

ahamai> а какие бывают текстовые игры, применимые в эхах?
ahamai>
ahamai> помню в ru.golovolomka в данетки играли. в vga.planets, вроде, только нетмейлом играли, как там эхи использовались, не вспомню. кто ещё что может вспомнить?

В быки-коровы можно играть везде, где есть запрос-ответ, хоть морзянкой.

Вот тут я пытался это пообсуждать месяц назад:

ii://c8zTIjCQQ1RyAA264WnN

Вот тут можно тред поглядеть:

http://tgistation.ru/echo/subj/8/%D0%98%D0%B3%D1%80%D1%8B%2520%D0%BF%D0%BE%2520ii%2520/

P.S. Надо у меня чтоли тоже показ тредов поддержать, но только не линейно, а деревом - как на ixbt было или как комменты на слешдоте например…

у меня тред 404 выдаёт. подними тему, чтобы на hugeping в форумах высвечивалась :)

ну как минимум в беседке была викторина, основаная на каком-то irc-боте, типа даёт вопрос и вариант п****ц, потом открывает буквы

Странно - линк не открывается:

http://tgistation.ru/echo/subj/8/%D0%98%D0%B3%D1%80%D1%8B%2520%D0%BF%D0%BE%2520ii%2520/

А через ping?

https://hugeping.tk/forum/c8zTIjCQQ1RyAA264WnN/1

Ага. Интересно. А что если играть в текстовые игры на instead? Я за последние лет 15 или сколько там, прошёл ровно одну игру, "День яблока". Остальные не осилил. Кота и ещё несколько игр прошёл только по солюшнам, потому что сам даж не знал чё там и где.

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

Ну и всё это сделать эксклюзивом нашей сети. Я помню, как году в 1997 играли в дюк нюкем на одной клавиатуре толпой, кто-то отвечал за стрельбу, кто-то за прыжки, кто-то за передвижение. Это было весело. И так, можно толпой проходить игру, и больше ответственности, и больше интереса.

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

Может тогда как-то почётче это в стандарте про push проговорить?

да, я так и поставил, вроде всё работает как и задумано

у меня вроде вообще не было стандарта на push, я его и не поддерживал, но в push-нодах всегда был отдельный пароль

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

ahamai> Ничё не понял. Если щас задать несколько эх и дать срез, он со всех по n сообщений запросит или только с последнего

Со всех, если я правильно понял типавопрос.

+++ Caesium/0.4 RC1

ahamai> Тогда не понял, почему стандарт такой, если в каждой эхе разное количество новых сообщений. :) Ладно, поняли-разобрались. Стандарт читал но как-то не задумывался об этом, задумался только сегодня в тронвае :)

Потому что не надо байто**ить. Сильно помогает в подавляющем числе случаев.

ahamai> 2shaos - фетчеры обновил

+++ Caesium/0.4 RC1

ahamai> у меня sf работает так: запрос вида /u/e/эха1/эха2/эха3?sf=хэш1/хэш2/хэш3, и она ищет указанные хэши в эхах, если находит, начинает выдачу эх с них. сначала не вклчая сами хэшN, но несколько дней назад я сделал, чтобы включали, на всякий случай, 21 байта не жалко, зато можно убедиться, какой именно хэш

А если хеш в блеклисте или вообще удалён? Ну и сложно это в реализации и не особо незачем.

+++ Caesium/0.4 RC1

>> По хорошему особый сисоповский должен быть. Потому что пуш для межузлового взаимодействия. Поини в принципе не может слать пуш, так как в пуше уже зарегистрированные сообщения летят, а не пользовательские.
shaos> Может тогда как-то почётче это в стандарте про push проговорить?

Хорошо. Принимается.

+++ Caesium/0.4 RC1

А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

У нас нельзя передавать файлы в общем случае. Да и бородачи нынче не те. Я так и не освоил новый интерфейс.

+++ Caesium/0.4 RC1

tuple> А ещё можно передавать сохранения игр, проходя их по очереди. Те же дварфы (dwarf fortress). Много чего можно сочинить.

Можно передавать уровни сокобана в plaintext-формате (.sok).

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

реализация и sf и lim у меня это всего несколько строчек.

было

def echoareas(names):
    out = ''
    for ea in names:
        out += ea + '\n' + get_echoarea(ea,True)
    return out

стало

def echoareas(names, sf, lim=0):
    out = ''
    if sf: sf = set(sf.split('/'))
    for ea in names:
        dllist = get_echoarea_f(ea)
        if sf:
            newhash = [x for x in dllist if x in sf]
            if newhash:
                dllist = dllist[dllist.index(newhash[0]):]
        if lim: dllist = dllist[-lim:]
        dllist = '\n'.join(dllist)
        if dllist: dllist += '\n'
        out += ea + '\n' + dllist
    return out

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

> Можно передавать уровни сокобана в plaintext-формате (.sok).

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

- если сообщений в базе мало
+ если новых сообщений в эхах разное количество, непонятно почему просто не запрашивать с каждой нужное (ну, или, с гарантией +1, +5 сообщений, это небольшой оверхед, по сравнению со случаем когда опращиваются одним запросом эхи с 1 и 110 сообщениями)
111
Вообще, связка h и sf реально сокращает количество запросов и реально экономит трафик. Если это кому-то важно.

> Можно передавать уровни сокобана в plaintext-формате (.sok).

А если и играть через эху? ;)

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

Во-первых, формат. /u/e/ чётко определён, там перечисляются эхи. Почему не использовать что-то типа ?s=-100:100 или любой другой способ? Если в фетчер ii 0.3 просунуть такой формат url и запросить что-то с ii 0.3, фетчер упадёт, не растоссив пакет, потому что будет считать -100:100 хэшем сообщения. Зачем плодить неоднозначность просто на ровном месте, там, где есть куча способов её избежать?

Ладно, раз уж решили изнасиловать формат /u/e, почему не использовать /u/e/эха/срез/эха/срез. Это же для экономии трафика всё затевалось? А какая экономия, если у тебя может быть куча эх, и ради одной роботной, где всегда куча сообщений, тянется куча ненужных? А если поодиночке - то это лишние запросы, на медленном и нестабильном интернете каждый запрос это всегда больно, и он может даже не состояться (поэтому links решал там, где opera не могла ни одного сайта открыть). Формат /u/e был придуман ровно для того, что дёргать /e на каждую эху было медленно и неэффективно. Изначально были только /e и /m, но всё это было медленно и печально.

>>^^<><>>...<><>... я выиграл?

кривая и косая версия adventure. играть можно только на моей станции

http://ii.blcat.ru/play.advent

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

по одному ходу скучно, надо сразу по много

тем более что sokoban игра с полной информацией и ходами только с одной стороны, её можно пройти одной командой

Ещё есть вариант найти мастера, сыграть в D&D.

P.S. Чур я бард-человек.

> Ещё есть вариант найти мастера,

тут новые пользователи появляются раз в пятилетку... :)

Складывается впечатление, что idec это пример плохого проектирования. Зачем менять устоявшуюся структуру запроса /u/e если можно этого не делать? Зачем вводить ограничение "количество сообщений в эхе может не совпадать со счётчиком", если можно этого не делать?

Формат /u/e был именно только для списка эх. Зачем добавлять туда что-то ещё? Почему не использовать, например /u/e?s=срез? Это значительно всё упрощает, это можно сувать куда угодно без разбора. А так алгоритм отдачи "всё эха" меняется на "последняя эха может быть не эхой":

ВЕСЬ ЗАПРОС СПИСОК ЭХ
ПОЛУЧИЛИ СПИСКИ
ЕСЛИ ЕСТЬ ЛИМИТ, УСТАНОВИЛИ

становится

ПОЛУЧИЛИ СПИСОК ЭХ
ПРОВЕРИЛИ ПОСЛЕДНЮЮ
ЕСЛИ ЭТО СРЕЗ, ТО РАСПАРСИЛИ СРЕЗ
СОХРАНИЛИ ЛИМИТ
УДАЛИЛИ ПОСЛЕДНЮЮ ЭХУ
ПОЛУЧИЛИ СПИСКИ
УСТАНОВИЛИ ЛИМИТ, ЕСЛИ ЕСТЬ

Команда lim появилась добавлением одного роута и одной строчки кода. Совместима с любым ii, хоть с ii-txt-0.1preprepre.

При этом корёжится список:
http://ii.blcat.ru/u/e/blcat.test/-100:100

ЧТО ТЫ ТАКОЕ? Эха? Нет точки, не эха. MSGID? по логике вроде бы да. У меня софт в расчёте на минималистичность и читаемость кода призван валиться при любых невалидных данных, а не разбираться, что это за ёжик.

Тут же появляется x/features. Это на каждый фетч надо ещё один запрос делать? Это не экономия трафика, это его расход. С какой-нибудь ?s= можно просто гонять url-ы и на любой клиент и на любой сервер, не задумываясь, поймёт ли он. А тут получается, надо прочитать x/features, потом подстроиться под сервера, давать ему срез или не давать. Лишний код, лишний трафик, лишнее переусложнение.

Сами же срезы не решают основной задачи "получить все нужные msgid одним запросом". Тебе нужно или обходить эхи по-очереди (привет, /e, от которого специально уходили для ускорения работы), или получать лишние сообщения. В стандарте не предусмотрено "хочу брать столько сообщений оттуда-то".

Кстати, ?sf потребовал добавления, по-моему, 4х строк кода и изменения одной. И он решает вопрос "получить только нужные msgid из нужных эх одним запросом".

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

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

ps. ?sf и ?h появились раньше, чем был сформирован стандарт iDEC.

добавил в архив сравнение станций

http://ii.blcat.ru:50000/compare

чёто боты по all=1 долбятся, сервер грузят, надо будет недоделанный архив скоро погасить, доделать, разобрать и перебрать

смотрю я на это и думаю, а давайте ru.humor.14 на бон вернём?

Не надо драматизировать :)

Индексы тоже пару строк кода добавляют (ну может чуть больше)

Для разнообразия можно множественные "слайсы" тоже сделать, типа

/u/e/echo.1/echo.2/-1:1/echo.3/-100:100/echo.4

будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

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

> будет означать, что echo.1 и echo.2 должны вернуть одно последнее сообщение, echo.3 должно вернуть 100 последних, а echo.4 должно вернуть всё - в этом случае всё будет логично и гибко ;)

если менять это, то надо убирать неэхи из стрки для эх. чтобы оно прозрачно накладывалось, а не как у меня пишет -100:100 в файле списка, потому что на это вообще не рассчитвалась. в /u/e должны быть только эхи, это изначальный стандарт

Интересно, что ii.stat я взял с таверны, и сам добавляю туда еженедельную статистику, а там остался старый вариант остановившийся в 2018 году :)

Люди, дайте ii.14 у кого есть? Очень хочется в промежуточную историю окунутся между тем что было на alicorn и тем что сейчас - я письмо ake написал (у него на станции было), но он не отвечает...

Ещё момент - lor-opennet.17 есть в таверне тоже, только она там глючит (сразу после сбойного сообщение оно размножается)

> кто будет переписывать цезий или фетчеры под замену стандартов?

никто - сервер может поддерживать и ванильный ii без индексов, и старый IDEC где индексы в конце, и новый многоиндексный вариант - ничто ничему не противоречит!

> если менять это, то надо убирать неэхи из стрки для эх

очевидно, что запись [-]N:M не является эхой т.к. там не точка, а двоеточие (и может быть минус вначале)

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

> Индексы тоже пару строк кода добавляют (ну может чуть больше)

Ну ок не 2 строки, а 20, но тем не менее :)

elseif ($opts[0] == 'u' and $opts[1] == 'e') {
        $work_options=array_slice($opts, 2);
        $w_opts_count=count($work_options);

        if (
                $w_opts_count > 1 and
                strstr($work_options[$w_opts_count-1], ":")!==false
        ) {
                $buffer="";
                $numbers=explode(":", $work_options[$w_opts_count-1]);

                $a=intval($numbers[0]);
                $b=intval($numbers[1]);

                $echoareas=array_slice($work_options, 0, $w_opts_count-1);
                $messages=[];

                foreach ($echoareas as $echo) {
                        $slice = $access->getMsgList($echo, $a, $b);

                        if (count($slice) > 0) {
                                $buffer.=$echo."\n".implode("\n", $slice)."\n";
                        } else {
                                $buffer.=$echo."\n";
                        }
                }
                echo $buffer;

        } else {
                foreach($work_options as $echo) {
                        echo $echo."\n".implode("\n", $access->getMsgList($echo))."\n";
                }
        }
}

Это так в ii-php и я думаю не сильно сложнее будет поддержать "слайсы" в любом месте строки, а не только в конце...

Можно хоть xml регекспами парсить. Я спрашиваю зачем добавлять в список эх что то ещё, делать проверки которые можно было не делать, терять в прозрачности, если всё это можно было сделать кучей способов, каждый из которых лучше. Какую проблему решили добавив неэховую инфу в /u/e?

Блин как эти ==== в этом ii-php работают? Ненавижу регулярные выражения...